wake-up-neo.com

Messung der Abfrageleistung: "Ausführungsplan-Abfragekosten" vs. "Zeitaufwand"

Ich versuche, die relative Leistung von zwei verschiedenen Abfragen zu ermitteln und habe zwei Möglichkeiten, dies zu messen:
1. Führen Sie beides aus und messen Sie jede Abfrage
2. Führen Sie beide aus und ermitteln Sie die "Abfragekosten" aus dem tatsächlichen Ausführungsplan

Hier ist der Code, mit dem ich die Abfragen zeitlich steuere ...

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

Was ich bekomme, ist das Folgende:

Stored_Proc     Execution_Time     Query Cost (Relative To Batch)

test_1a         1.673 seconds      17%
test_1b         1.033 seconds      83%

Die Ergebnisse der Ausführungszeit stehen in direktem Widerspruch zu den Ergebnissen der Abfragekosten, aber ich habe Schwierigkeiten zu bestimmen, was "Abfragekosten" tatsächlich bedeutet. Meine beste Vermutung ist, dass es sich um ein Aggregat aus Reads/Writes/CPU_Time/etc handelt, also habe ich vermutlich ein paar Fragen:

  1. Gibt es eine definitive Quelle, um zu erklären, was diese Maßnahme bedeutet?

  2. Welche anderen "Abfrageleistungs" -Metriken verwenden die Benutzer und welche relativen Vorteile haben sie?


Es ist möglicherweise wichtig zu wissen, dass dies ein mittelgroßer SQL Server ist, auf dem MS SQL Server 2005 unter MS Server 2003 Enterprise Edition mit mehreren Prozessoren und über 100 gleichzeitigen Benutzern ausgeführt wird.

BEARBEITEN:

Nach einigem Hin und Her habe ich es geschafft, Profiler-Zugriff auf diesen SQL Server zu erhalten und kann zusätzliche Informationen bereitstellen (die die Abfragekosten in Bezug auf Systemressourcen unterstützen, nicht die Ausführungszeit selbst ...)

Stored_Proc    CPU      Reads    Writes   Duration   

test_1a        1313     3975     93       1386
test_1b        2297     49839    93       1207

Beeindruckend, dass das Aufnehmen von mehr CPU mit VIELEN mehr Lesevorgängen weniger Zeit kostet :)

48
MatBailie

Die Profiler-Ablaufverfolgung relativiert es.

  • Abfrage A: 1,3 Sekunden CPU, 1,4 Sekunden Dauer
  • Abfrage B: 2,3 Sekunden CPU, 1,2 Sekunden Dauer

Abfrage B verwendet Parallelität: CPU> Dauer. Die Abfrage verwendet z. B. 2 CPUs mit einem Durchschnitt von jeweils 1,15 Sekunden

Abfrage A ist wahrscheinlich nicht: CPU <Dauer

Dies erklärt die Kosten im Verhältnis zur Charge: 17% der Kosten für den einfacheren, nicht parallelen Abfrageplan.

Das Optimierungsprogramm stellt fest, dass die Abfrage B teurer ist und von der Parallelität profitiert, obwohl dies zusätzlichen Aufwand erfordert.

Denken Sie jedoch daran, dass Abfrage B ungefähr eine Sekunde lang 100% von 2 CPUS (also 50% für 4 CPUs) verwendet. Abfrage A verwendet 1,5 Sekunden lang 100% einer einzelnen CPU.

Der Spitzenwert für Abfrage A ist niedriger, was zu einer längeren Dauer führt. Mit einem Benutzer, wen interessiert das? Mit 100 macht es vielleicht einen Unterschied ...

34
gbn
SET STATISTICS TIME ON

SELECT * 

FROM Production.ProductCostHistory
WHERE StandardCost < 500.00;

SET STATISTICS TIME OFF;

Und siehe die Nachricht Registerkarte wird es so aussehen:

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.
12
Aditya Acharya

Die Ergebnisse der Ausführungszeit stehen in direktem Widerspruch zu den Ergebnissen der Abfragekosten, aber ich habe Schwierigkeiten zu bestimmen, was "Abfragekosten" tatsächlich bedeutet.

Query cost gibt an, wie lange die Abfrage nach Meinung des Optimierers dauern wird (im Verhältnis zur gesamten Stapelzeit).

Das Optimierungsprogramm versucht, den optimalen Abfrageplan auszuwählen, indem es sich Ihre Abfrage und die Statistik Ihrer Daten ansieht, mehrere Ausführungspläne ausprobiert und den kostengünstigsten auswählt.

Hier können Sie ausführlicher lesen, wie es versucht, dies zu tun.

Wie Sie sehen, kann dies erheblich von dem abweichen, was Sie tatsächlich erhalten.

Die einzige echte Metrik für die Abfrageleistung ist natürlich, wie lange die Abfrage tatsächlich dauert.

5
Quassnoi

Verwenden SET STATISTICS TIME ON

über Ihrer Anfrage.

Unterhalb der Registerkarte "In der Nähe von Ergebnissen" sehen Sie eine Registerkarte "Nachricht". Dort können Sie die Zeit sehen.

4
NMK

Ich verstehe, dass es sich um eine alte Frage handelt. Ich möchte jedoch ein Beispiel hinzufügen, bei dem die Kosten gleich sind, eine Abfrage jedoch besser ist als die andere.

Wie Sie in der Frage festgestellt haben, ist% im Ausführungsplan nicht der einzige Maßstab für die Ermittlung der besten Abfrage. Im folgenden Beispiel habe ich zwei Abfragen, die dieselbe Aufgabe ausführen. Der Ausführungsplan zeigt, dass beide gleich gut sind (jeweils 50%). Jetzt habe ich die Abfragen mit SET STATISTICS IO ON was deutliche Unterschiede zeigt.

Im folgenden Beispiel verwendet die Abfrage 1 seek, während Abfrage 2 scan für die Tabelle LWManifestOrderLineItems verwendet. Wenn wir jedoch die Ausführungszeit überprüfen, stellen wir fest, dass Abfrage 2 besser funktioniert.

Lesen Sie auch Wann ist eine Suche keine Suche? von Paul White

[~ # ~] Abfrage [~ # ~]

---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  

Statistik IO

enter image description here

Ausführungsplan

enter image description here

2
Lijo

Ausführungszeit der Abfrage:

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] 

Die Ausgabe der Abfrage lautet wie folgt:

enter image description here

So optimieren Sie die Abfragekosten:

Klicken Sie auf Ihr SQL Management Studio

enter image description here

Führen Sie Ihre Abfrage aus und klicken Sie auf Ausführungsplan neben der Registerkarte Nachrichten Ihres Abfrageergebnisses. Sie werden gerne sehen

enter image description here

1
atik sarker