La mesure de la Performance de la Requête : “Plan d'Exécution de Requête Coût” vs “Temps”

Je suis en train de déterminer la performance relative des deux requêtes différentes et ont deux façons de mesurer ce qui s'offrent à moi:

1. Exécuter à la fois et l'heure de chaque requête

2. Exécuter à la fois et d'obtenir de la Requête "Coût" de l'actuel plan d'exécution

Voici le code que j'ai exécuter à temps les requêtes...

DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
DECLARE @start DATETIME SET @start = getDate()
EXEC test_1a
SELECT getDate() - @start AS Execution_Time
GO

DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
DECLARE @start DATETIME SET @start = getDate()
EXEC test_1b
SELECT getDate() - @start AS Execution_Time
GO

Ce que j'ai est le suivant:

Stored_Proc     Execution_Time     Query Cost (Relative To Batch)

test_1a         1.673 seconds      17%
test_1b         1.033 seconds      83%

Les résultats de l'exécution du temps en contradiction directe avec les résultats de la Requête Coût, mais je vais avoir de la difficulté à déterminer ce que "le Coût de Requête" signifie réellement. Ma meilleure supposition est que c'est un ensemble de Lectures/Écritures/CPU_Time/etc, donc je suppose que j'ai un couple de questions:

Est-il un definative source d'expliquer en quoi cette mesure signifie?
Ce que les autres "les Performances de la Requête" paramètres n'gens utilisent, et quels sont leurs mérites?

Il peut être important de noter que c'est un de taille moyenne SQL Server, exécutez MS SQL Server 2005 sur MS Server 2003 Enterprise Edition avec plusieurs processeurs et+ de 100 utilisateurs simultanés.

EDIT:

Après quelques la peine, j'ai réussi à obtenir Profiler l'accès à SQL Server, et peut donner des infos supplémentaires (Qui prend en charge le Coût des Requêtes liées à des ressources du système, pas de Temps d'Exécution lui-même...)

Stored_Proc    CPU      Reads    Writes   Duration   

test_1a        1313     3975     93       1386
test_1b        2297     49839    93       1207

Impressionnant que la prise de plus de CPU avec BEAUCOUP plus de Lectures prend moins de temps 🙂

InformationsquelleAutor MatBailie | 2009-02-19

36

La trace du générateur de profils met en perspective.
- Requête: 1.3 secondes de CPU, de 1,4 secondes durée
- La requête B: 2.3 secondes CPU, 1.2 secondes de la durée
La requête B est à l'aide du parallélisme: CPU > durée
par exemple, la requête utilise les 2 CPUs, moyenne de 1,15 secondes de chaque

Une requête est probablement pas: CPU < durée

C'est ce qui explique les coûts relatifs aux lots: 17% de la pour le plus simple, non-plan de requête parallèle.

L'optimiseur de travaux que la requête B est plus cher et bénéficier du parallélisme, même si elle prend l'effort supplémentaire à faire.

N'oubliez pas, cependant, que la requête B utilise 100% de 2 PROCESSEURS (donc 50% pour les 4 Processeurs) pendant une seconde ou deux. Requête à Un usage 100% d'un seul PROCESSEUR de 1.5 secondes.

La pointe pour Une requête est inférieure, à la charge de l'accroissement de la durée.
Avec un seul utilisateur, qui s'en soucie? Avec 100, peut-être qu'il fait une différence...
- Connaissez-vous toutes les ressources que je peux utiliser pour en savoir plus sur Requête de l'Évaluation des coûts du Régime?
- ce cours est une bonne source pour aider à la compréhension de la requête coûts> youtube.com/playlist?list=PLSE8ODhjZXjbisIGOepfnlbfxeH7TW-8O
InformationsquelleAutor gbn

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.

InformationsquelleAutor Aditya Acharya

5

Les résultats de l'exécution du temps en contradiction directe avec les résultats de la Requête Coût, mais je vais avoir de la difficulté à déterminer ce que "le Coût de Requête" signifie réellement.

Query cost est ce que l'optimiseur pense à combien de temps votre requête (par rapport au total des lots du temps).

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 en sélectionnant le moins cher 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 sensiblement de ce que vous obtenez en fait.

La seule vraie requête perfomance métrique est, bien sûr, combien de temps dure la requête fait prendre.

InformationsquelleAutor Quassnoi
4

Utilisation SET STATISTICS TIME ON

au-dessus de votre requête.

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

InformationsquelleAutor NMK
2

Temps D'Exécution Requête:
```
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] 
```
De requête de Sortie Sera Comme:

Pour Optimiser Le Coût De Requête :

Cliquez sur votre SQL Management Studio

D'exécuter votre requête et cliquez sur l'Exécution du plan à côté de l'onglet Messages de votre résultat de la requête. vous verrez comme
- Il y a une erreur dans votre code. Vous passez NS (nanosecondes) en tant que paramètre à DATEDIFF mais vous avez nommé le résultat sous la forme d'une Durée de millisecs' SELECT DATEDIFF(NS,@StartTime,@EndTime) AS [Duration in millisecs] devrait être SELECT DATEDIFF(MILLISECOND,@StartTime,@EndTime) AS [Duration in millisecs]
InformationsquelleAutor atik sarker
2

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.

Que vous avez observé dans la question, % 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 les deux sont tout aussi bonne (50% chacun). Maintenant, j'ai exécuté les requêtes avec SET STATISTICS IO ON qui montre clairement les différences.

Dans l'exemple suivant, la requête 1 utilise seek considérant que la Requête 2 utilise scan sur la table LWManifestOrderLineItems. Quand on vérifie le temps d'exécution il est toutefois trouver que la Requête 2 fonctionne mieux.

Également lire Quand un Chercher pas Chercher? par Paul Blanc

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
- Certaines personnes utilisent DBCC SETCPUWEIGHT(100000000) (sans-papiers) pour vérifier la performance de test/développement des serveurs. Et qui se souvient de la définir à 1, la commande DBCC SETCPUWEIGHT(1) et un cache.
- La référence pour cette fonction non documentée - sqlblog.com/blogs/paul_white/archive/2010/09/01/...
InformationsquelleAutor LCJ

Vous devez vous connecter pour publier un commentaire.