Pour répondre à cette question, regardez les plans de requête produits par les deux.
Le premier SELECT est un simple parcours de table, ce qui signifie qu'il produit des lignes dans l'ordre d'allocation. Comme il s'agit d'une nouvelle table, elle correspond à l'ordre dans lequel vous avez inséré les enregistrements.
Le deuxième SELECT ajoute un GROUP BY, que SQL Server implémente via un tri distinct puisque le nombre de lignes estimé est si faible. Si vous aviez plus de lignes ou si vous ajoutiez un agrégat à votre SELECT, cet opérateur pourrait changer.
Par exemple, essayez :
CREATE TABLE #Values ( FieldValue varchar(50) )
;WITH FieldValues AS
(
SELECT '4' FieldValue UNION ALL
SELECT '3' FieldValue UNION ALL
SELECT '2' FieldValue UNION ALL
SELECT '1' FieldValue
)
INSERT INTO #Values ( FieldValue )
SELECT
A.FieldValue
FROM FieldValues A
CROSS JOIN FieldValues B
CROSS JOIN FieldValues C
CROSS JOIN FieldValues D
CROSS JOIN FieldValues E
CROSS JOIN FieldValues F
SELECT
FieldValue
FROM #Values
GROUP BY
FieldValue
DROP TABLE #Values
En raison du nombre de lignes, cela se transforme en un agrégat de hachage, et maintenant il n'y a plus de tri dans le plan de requête.
Sans ORDER BY, SQL Server peut renvoyer les résultats dans n'importe quel ordre, et l'ordre dans lequel il revient est un effet secondaire de la façon dont il pense pouvoir renvoyer les données le plus rapidement.