SQL Server ORDER BY Performance Aberration

Question

SQL Server 2008 fonctionnant sous Windows Server Enterprise (?) Edition 2008

J'ai une requête contre se joindre à vingt-impair quelques tables (principalement LEFT OUTER JOIN). L'ensemble de données complet renvoyé par une requête non filtrée renvoie moins de 1 000 lignes en moins de 1 seconde. Lorsque j'applique une clause WHERE pour filtrer la requête, elle renvoie moins de 300 lignes en moins de 1 seconde.

Lorsque j'applique une clause ORDER BY à la requête renvoyée dans les années 90. J'ai examiné les résultats de la requête et noté un nombre de résultats NULL retournés dans la colonne utilisée pour trier. J'ai modifié la requête à COALESCE une valeur NULL à une valeur de recherche valide sans aucune modification de la performance de la requête.

J'ai alors fait un

SELECT * FROM 
(
my query goes here 
) qry 
ORDER BY myOrderByHere 

Et qui ont produit les mêmes résultats.

Lorsque je sélectionne ... INTO #tempTable (sans ORDER BY), puis SELECT FROM du paramètre #tempTable avec l'ordre de la requête renvoie moins de 1s. Ce qui est vraiment étrange à ce stade est que le SELECT ... INTO prendra aussi 90s même sans ORDER BY. Le plan d'exécution indique que le tri prend 98% du temps d'exécution lorsqu'il est inclus dans la requête principale. Si je fais INSERT INTO, le plan explicite indique que l'insertion réelle dans la table temporaire prend 99% du temps d'exécution.

Et pour supprimer les problèmes de serveur, j'ai exécuté les mêmes tests sur deux instances différentes de SQL Server 2008 avec des résultats presque identiques.

Merci beaucoup!

rjsjr

Answer 1

Une opération de tri est généralement une étape coûteuse dans la requête. Donc, il n'est pas surprenant que l'ajout du tri ajoute du temps. Vous pouvez voir des résultats similaires lorsque vous incorporez une table temporaire dans vos étapes. L'opération de tri de votre requête d'origine peut utiliser tempdb pour faciliter le tri, ce qui peut prendre beaucoup de temps dans chaque requête que vous comparez.

Si vous souhaitez en savoir plus sur chaque requête que vous exécutez, vous pouvez consulter les résultats du plan de requête.

Answer 2

Il semble que quelque chose d'étrange se passe avec votre tempdb. L'insertion de 1000 lignes dans une table temporaire doit être rapide, qu'il s'agisse d'une file d'attente implicite pour le tri, ou d'un select into explicite.

Vérifiez la taille de votre tempdb, la santé du disque dur, il est sur, et il est le modèle de récupération (qui devrait être simple, pas full ou bulk logged.)