web-dev-qa-db-fra.com

Temps CPU ou temps écoulé - Qu'est-ce qui signifie réellement les performances de SQL Query?

J'ai une table SQL Server 2012 avec 2697 enregistrements et la table n'est pas indexée. Les données seront augmentées à l'avenir jusqu'à 100 000 enregistrements. Je ne joins aucune autre table à celle-ci pour récupérer des enregistrements. Au départ, j'ai créé une fonction définie par l'utilisateur pour récupérer les enregistrements de la table.

Plus tard, j'ai appris qu'une vue sera plus rapide que la fonction définie par l'utilisateur et j'ai donc créé une vue pour cette table.

Pour connaître les performances de la requête, j'ai inclus les codes ci-dessous pour obtenir le temps CPU et le temps écoulé de mon UDF, VIEW et instruction SQL directe.

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

Lorsque j'ai extrait les données directement de ma table avec une requête de sélection, j'ai obtenu le temps CPU et le temps écoulé ci-dessous

SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata]

---- Résultat

Scan count 1, logical reads 1338, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
 SQL Server Execution Times:
   CPU time = 31 ms,  elapsed time = 4381 ms.

Lorsque j'ai utilisé VIEW, j'ai obtenu le temps CPU et le temps écoulé comme

CREATE VIEW vw_testdata
AS
SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata]

-- Résultat

Scan count 1, logical reads 1324, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
       CPU time = 15 ms,  elapsed time = 5853 ms.

Et mon UDF est revenu comme

CREATE FUNCTION [dbo].[fn_DocApproval] (@collegename nvarchar(30) = NULL)
RETURNS TABLE 
AS
RETURN  
(
SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata] WHERE CollegeName = ISNULL(@collegename, collagename)
)

-- Résultat

Scan count 1, logical reads 1338, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
 SQL Server Execution Times:
   CPU time = 203 ms,  elapsed time = 785 ms.

L'UDF a un temps écoulé très inférieur à celui du SQL direct et de la vue, mais le temps CPU est plus long.

Cependant, le temps CPU est inférieur dans la vue par rapport à SQL direct et UDF.

Je veux savoir lequel nous devons rechercher pour déterminer les performances de la requête.

Aussi pourquoi le temps CPU et le temps écoulé changent-ils lorsque j'exécute la même requête à chaque fois?

Mon schéma et des exemples de données Fiddle

J'ai actuellement 2697 lignes et je ne peux pas les charger toutes au violon.

sql-serverperformancequery-optimization
15
Karthik Venkatraman

Selon l'article optimisation des performances de la requête SQL

Analyse et compilation de SQL Server: lorsque nous soumettons une requête à SQL Server pour l'exécuter, il doit analyser et compiler pour toute erreur de syntaxe et l'optimiseur doit produire le plan optimal pour l'exécution. L'analyse SQL Server et le temps de compilation se réfèrent au temps nécessaire pour terminer cette étape de pré-exécution.Si vous examinez la sortie de la deuxième exécution, le temps CPU et le temps écoulé sont de 0 dans la section Analyse SQL Server et temps de compilation. Cela montre que SQL Server n'a pas passé de temps à analyser et compiler la requête car le plan d'exécution était facilement disponible dans le cache. Le temps processeur fait référence au temps réel passé sur le processeur et le temps écoulé se réfère au temps total nécessaire pour terminer l'analyse et la compilation. La différence entre le temps CPU et le temps écoulé peut attendre le temps dans la file d'attente pour obtenir le cycle CPU ou il attendait l'achèvement IO. Cela n'a pas beaucoup d'importance dans le réglage des performances comme valeur varie d'une exécution à l'autre. Si vous obtenez une valeur cohérente dans cette section, vous exécuterez probablement la procédure avec l'option de recompilation.

Temps d'exécution SQL Server: il s'agit du temps mis par le serveur SQL pour terminer l'exécution du plan compilé. Le temps CPU fait référence au temps réel passé sur le CPU où, comme le temps écoulé est le temps total pour terminer l'exécution qui inclut le temps d'attente du signal, le temps d'attente pour terminer l'opération IO et le temps nécessaire pour transférer la sortie vers le client.Le temps processeur peut être utilisé pour baseline l'optimisation des performances. Cette valeur ne variera pas beaucoup d'exécution à exécution sauf si vous modifiez la requête ou les données. La charge sur le serveur n'aura pas beaucoup d'impact sur cette valeur. Veuillez notez que le temps indiqué est en millisecondes. La valeur du temps processeur peut varier d'une exécution à l'autre pour la même requête avec les mêmes données, mais ce ne sera que dans 100, ce qui n'est qu'une partie d'une seconde. Le temps écoulé dépendra de nombreux facteurs, comme la charge sur le serveur, IO, bande passante réseau entre le serveur et le client. Utilisez donc toujours le temps CPU comme ligne de base lors de l'optimisation des performances.

Plus le nombre de lectures logiques que vous avez dans le plan est faible, plus la requête est efficace.

12
user5242766

Si vous utilisez un serveur moderne, regardez toujours le "temps écoulé" et non le "temps CPU". À l'ère des processeurs multicœurs rapides, des cartes multiprocesseurs, etc. - tous les autres facteurs conditionnant une réponse rapide, et non un processeur, sont importants. Il arrive qu'avec des requêtes compliquées, l'indication du temps CPU soit 5 fois supérieure au temps total (vérifier "plan d'exécution" - alors il y aura de nombreux parallélismes).

1
Maciej Niemir