Pourquoi SQL Server 2008 ordonne-t-il lors de l'utilisation d'un GROUP BY et qu'aucun ordre n'a été spécifié ?

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.