Abfrage-Leistungsoptimierung

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?

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.

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, don’t 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.

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