Abfrage-Leistungsoptimierung

12

Was ist der informativste Weg, um schnell einige Leistungsparameter zu erhalten, wenn Sie mit dem Schreiben einer Abfrage / eines gespeicherten Prozesses / einer Funktion fertig sind? Führen Sie die Abfrage aus und zeigen Sie den tatsächlichen Ausführungsplan an? Wenn ja, wonach suchen Sie? Offensichtlich sind Tabellen- / Index-Scans die Bit-Treffer, aber was noch?


quelle

Antworten:

8

Laden Sie den Ausführungsplan für eine schnelle Beurteilung aus SSMS in den Plan Explorer .

  • Prüfen Sie die teuersten Vorgänge auf unerwartete Ereignisse. Sortierungen, Arbeitstabellen, unangemessene Verknüpfungsoperatoren (z. B. verschachtelte Schleife, in der Sie eine Zusammenführung oder einen Hash erwarten).
  • Sehen Sie sich die Zeilenanzahl in jeder Phase des Plans an. Liegen sie im Großen und Ganzen innerhalb des Bereichs, den Sie erwartet haben?
  • Schauen Sie sich die geschätzten und tatsächlichen Zeilen an. Wenn Ihre tatsächlichen Werte nahe an den Schätzungen liegen, ist es wahrscheinlicher, dass Sie einen guten Plan haben. Wenn es große Abweichungen gibt, finden Sie heraus, warum (fehlende und / oder veraltete Statistiken zum Beispiel).
  • Bewerten Sie das Potenzial für Parameter-Sniffing-Probleme. Suchen Sie nach Bereichen, in denen die Kardinalität variieren kann, und testen Sie sie anhand einer Reihe von Eingabeparametern.

Die SQL Server-Ausführungspläne von Grant Fitchley mit vielen frei verfügbaren Nachschlagewerken sind ein guter Anfang. Ich fand auch Joe Changs Blogposts und E-Books zu den Ausführungsplankosten sehr nützlich.

Mark Storey-Smith
quelle
5

Meistens führe ich nur die Abfrage aus und finde heraus, wie sie mit realen Daten ausgeführt wird. Wenn es ein Problem gibt, schaue ich mir die Ausführungspläne an.

Brad McGehee hat einen interessanten Artikel zu diesem Thema.

Darin sagt er:

Wenn Sie in einem Ausführungsplan eine der folgenden Angaben sehen, sollten Sie sie als Warnzeichen betrachten und sie auf potenzielle Leistungsprobleme untersuchen. Jeder von ihnen ist aus Sicht der Leistung weniger als ideal.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, dont include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Es ist nicht immer möglich, diese zu vermeiden. Je mehr Sie sie jedoch vermeiden können, desto schneller ist die Abfrageleistung.

Richard
quelle
0
SET STATISTICS IO ON

Im Allgemeinen sollte die "Anzahl der logischen Lesevorgänge" so gering wie möglich sein. Je weniger Seiten berührt wurden, um die Abfrage abzuschließen, desto besser ist der Plan, da er (normalerweise) schneller ist und die Auswirkungen auf CPU, RAM und Festplatten-E / A geringer sind.

Dies wird Ihnen helfen, wenn Sie die Indizes ändern oder das SQL neu faktorisieren. Wenn Sie sich die "Millisekunden-Ausführungszeit" ansehen, ändert sich diese auch mit demselben SQL- und Abfrageplan. Die logischen Lesevorgänge bleiben für einen bestimmten Abfrageplan konsistent.

Auch "physische Lesevorgänge" sollten sehr niedrig sein (und Null sein und für nachfolgende Ausführungen Null bleiben). Wenn dies nicht der Fall ist, überprüfen Sie Ihre SQL Server-Speichernutzung (Seitenlebensdauer usw.).

Kerl
quelle
Aber für Abfragen, die ausgeführt werden, wenn sie sich nicht im Abfragecache befinden, sind die physischen Lesevorgänge größer als Null, oder? Ich meine, Sie können das nicht immer umgehen, da nicht alle Abfragen (insbesondere Ad-hoc-Abfragen) zwischengespeichert werden. Hab ich recht?
Thomas Stringer
@ Surfer513 Um das Zwischenspeichern der Daten zu gewährleisten, können Sie einen CHECKPOINT gefolgt von einem DBCC DROPCLEANBUFFERS ausgeben, um den Pufferpool (Datencache) zu leeren. Beachten Sie, dass dadurch die Puffer für alle gelöscht werden. Verwenden Sie sie daher entsprechend (auf Testsystemen).
StanleyJohns
@ StanleyJohns, warum sollten Sie den Daten- / Abfrage-Cache löschen?
Thomas Stringer
Auf diese Weise ist die physische E / A jedes Mal dieselbe, was die zum Testen erforderliche Konsistenz ergibt. Dies hilft bei der Feinabstimmung der Abfrage.
StanleyJohns
Ich würde die physischen E / A-Statistiken ignorieren, da diese von der zugrunde liegenden Infrastruktur kontrolliert werden und SAN- und Betriebssystempufferung beinhalten. Logische E / A sind ein Maß für die Menge an ARBEIT, die die SQL-Anweisung ausführen musste. Wenn der SQL-Code weniger logische E / A-Vorgänge ausführt, funktioniert er weniger.
Guy