Mesure de la Performance de la requête: coût de la requête "Plan D'exécution" par rapport au temps pris"

SET STATISTICS TIME ON

SELECT * 

FROM Production.ProductCostHistory
WHERE StandardCost < 500.00;

SET STATISTICS TIME OFF;

Et voir l'onglet message, il ressemblera à ceci:

SQL Server Execution Times:

   CPU time = 0 ms,  elapsed time = 10 ms.

(778 row(s) affected)

SQL Server parse and compile time: 

   CPU time = 0 ms, elapsed time = 0 ms.

les résultats du temps d'exécution contredisent directement les résultats du coût de requête, mais j'ai de la difficulté à déterminer ce que" coût de requête " signifie réellement.

Query cost est ce que optimizer pense de la durée de votre requête (par rapport à la durée totale du lot).

L'optimiseur tente de choisir le plan de requête optimal en regardant votre requête et les statistiques de vos données, en essayant plusieurs plans d'exécution et choisir le moins coûteux d'entre eux.

Ici , vous pouvez lire plus en détail sur la façon qu'il ne tente de le faire.

comme vous pouvez le voir, cela peut différer considérablement de ce que vous obtenez réellement.

la seule vraie métrique de performance de requête est, bien sûr, combien de temps la requête prend réellement.

Utiliser SET STATISTICS TIME ON

au-dessus de votre requête.

ci-dessous, près de l'onglet résultat, vous pouvez voir un onglet message. De là, vous pouvez voir l'heure.

je comprends que c'est une vieille question – je voudrais toutefois ajouter un exemple où le coût est le même, mais une requête est mieux que l'autre.

comme vous l'avez fait remarquer dans la question, le pourcentage indiqué dans le plan d'exécution n'est pas le seul critère pour déterminer la meilleure requête. Dans l'exemple suivant, j'ai deux requêtes à faire la même tâche. Plan d'exécution montre que les deux sont également bons (50% chacun). Maintenant j'ai exécuté les requêtes avec SET STATISTICS IO ON qui montre des différences claires.

dans l'exemple suivant, la requête 1 utilise seek tandis que la requête 2 utilise scan sur la table LWManifestOrderLineItems. Quand nous vérifions réellement le temps d'exécution cependant il est de trouver que la requête 2 fonctionne mieux.

lire aussi quand une recherche n'est-elle pas une recherche? de Paul White

REQUÊTE

---Preparation---------------
-----------------------------
DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO

SET STATISTICS IO ON  --IO
SET STATISTICS TIME ON

--------Queries---------------
------------------------------

SELECT LW.Manifest,LW.OrderID,COUNT(DISTINCT LineItemID)
FROM LWManifestOrderLineItems LW
INNER JOIN ManifestContainers MC
    ON MC.Manifest = LW.Manifest
GROUP BY LW.Manifest,LW.OrderID
ORDER BY COUNT(DISTINCT LineItemID) DESC  

SELECT LW.Manifest,LW.OrderID,COUNT( LineItemID) LineCount
FROM LWManifestOrderLineItems LW
WHERE LW.Manifest IN (SELECT Manifest FROM ManifestContainers)
GROUP BY LW.Manifest,LW.OrderID
ORDER BY COUNT( LineItemID) DESC  

statistiques IO

Plan D'Exécution

Exécution De La Requête Du Temps:

DECLARE @EndTime datetime
DECLARE @StartTime datetime 
SELECT @StartTime=GETDATE() 


` -- Write Your Query`

SELECT @EndTime=GETDATE()
--This will return execution time of your query
SELECT DATEDIFF(MILLISECOND,@StartTime,@EndTime) AS [Duration in millisecs] 

Requête de Sortie Sera Comme:

Pour Optimiser Le Coût D'Interrogation:

cliquez sur votre Studio de gestion SQL

lancez votre requête et cliquez sur plan D'exécution à côté de L'onglet Messages de votre résultat de requête. vous verrez comme