Comment différencier le temps d'exécution de la durée totale d'exécution et de retour des lignes?

Question

Lorsque j'exécute une requête qui renvoie des millions de lignes à partir d'outils de gestion Sql, il semble que la requête s'exécute instantanément. Il n'y a pratiquement pas de temps d'exécution pour autant que je sache. Ce que la requête prend le temps de terminer renvoie toutes les lignes. Cela m'a fait penser que j'ai fait du bon travail! Mais pas si vite ... Comme je regarde la requête dans l'outil de profilage, il indique que la requête a utilisé 7600 CPU. La durée était de 15 000.

Je ne suis pas sûr de savoir comment interpréter ces statistiques. D'une part, la requête semble aller vite mais le rapport du profileur me fait penser autrement. Comment se fait-il que la requête soit exécutée instantanément dans Mgmt Tools? Il devrait évidemment y avoir une sorte d'exécution retardée autant que je peux dire: au moins 7600 ms. Je dois attendre plus longtemps que les stats de cpu et de durée quand j'exécute la requête dans les outils de mgmt pour qu'il complète la requête.

Answer 1

il semble que la requête s'exécute instantanément Il se peut que le plan de requête permette de commencer à retourner les lignes rapidement.
Par exemple, si vous faites SELECT * FROM a_large_table, vous verrez immédiatement des lignes, mais la récupération de l'ensemble de résultats prendra un certain temps. Quel est le temps d'exécution réel rapporté par Mgmt Studio (indiqué dans la barre d'état une fois la requête terminée)?

Si vous souhaitez tester les performances de la requête sans récupérer les données sur le client, vous pouvez effectuer SELECT INTO #temp_table. Cela nécessiterait des E/S supplémentaires, mais vous donnerait quand même une assez bonne estimation du temps d'exécution.

UPD.
Vous pouvez également exécuter quelque chose comme SELECT COUNT(*) FROM (<your query here>) ou SELECT SUM(<some field>) FROM (<your query here>) - avec un peu de chance, le serveur exécutera la requête et agrègera le résultat, effectuant essentiellement le même travail et un peu plus. Mais il est très facile de fausser les résultats de cette façon - l'optimiseur de requêtes est intelligent, et vous devez être très prudent pour être sûr de mesurer ce que vous voulez mesurer (car mesurer une requête avec un plan d'exécution différent n'a aucun sens)).

Je vous suggère de réfléchir à nouveau sur ce que vous voulez mesurer et pourquoi. Dans un scénario réel, vous n'êtes pas intéressé par la durée "pure" de la requête, car vous ne voulez jamais supprimer le résultat de la requête (le résultat est la raison pour laquelle vous avez besoin de cette requête, n'est-ce pas?). Vous devez donc soit renvoyer le résultat au client, soit le stocker quelque part, soit le joindre à une autre table et ainsi de suite. En général, vous souhaitez mesurer l'exécution de la requête, y compris le temps utilisé pour traiter son résultat.

Un dernier avis. Si vous espérez que vous pouvez forcer le serveur à exécuter cette requête en 1 seconde parce que vous pensez que le serveur ne fait rien pendant les 13 secondes suivantes, vous avez tort. Comme ils le disent, SELECT n'est pas cassé.
Ce qui peut aider est l'optimisation des requêtes - et pour une seule requête, un profileur ne vous aidera pas beaucoup. Analysez le plan de requête, ajustez la structure de votre table, essayez de réécrire la requête, postez une autre question sur SO en cas de problème.