Einführung
Die SQL-Abfrage beschreibt das erwartete Ergebnis, nicht den Weg, um das Ergebnis zu erhalten. Der Satz spezifischer Schritte, die der Server ausführen muss, um das Ergebnis zurückzugeben, wird als Abfrageausführungsplan bezeichnet. Der Plan wird vom Optimierer erstellt. Die Auswahl eines Plans wirkt sich auf die Ausführungsgeschwindigkeit aus, was ihn zu einem der wichtigsten Elemente der Analyse von Abfrageleistungsproblemen macht.
Ausführungsplan umfasst Operatoren und deren Eigenschaften, die in Form der Baumstruktur miteinander in Beziehung stehen. Jeder Bediener ist für eine separate logische oder physische Operation verantwortlich. Zusammen sorgen sie für das im Abfragetext beschriebene Ergebnis. Innerhalb der Struktur werden Operatoren durch die Klassenobjekte im Speicher von SQL Server dargestellt. Serverbenutzer (d. h. Sie und ich) sehen die im XML-Format generierte Beschreibung mit einem bestimmten Schema, das von der SQL Server Management Studio (SSMS)-Umgebung grafisch angezeigt wird.
Es gibt viele verschiedene Planbetreiber und noch mehr Eigenschaften. Außerdem kommen von Zeit zu Zeit neue hinzu. Dieser Artikel wagt es nicht, alle möglichen Operatoren zu beschreiben. Stattdessen möchte ich die interessantesten Ergänzungen zu diesem Thema teilen und einige alte, aber nützliche Elemente in Erinnerung rufen.
Serverversion
Manchmal finden Sie in den Foren Anfragen für die Serverversion, auch wenn der Abfrageplan im richtigen Format (XML) bereitgestellt wird. Stattdessen können Sie Zeit sparen und den Ausführungsplan als XML öffnen. Und das erste Element, das den Plan beschreibt, zeigt Ihnen die Serverversion in der Build-Eigenschaft.
Diese Methode ermöglicht es nicht, vollständige Informationen über die Serveredition abzurufen, aber in den meisten Fällen reicht es aus, um zu verstehen, womit wir es zu tun haben.
Anzahl der Tabellenzeilen
Die zweite häufige Frage lautet:„Wie viele Zeilen enthält Ihre Tabelle?“. Diese Informationen können auch aus dem Abfrageplan (ab Serverversion 2008) abgerufen werden. Dazu müssen wir den Datenzugriffsoperator (Scan oder Seek) einer betreffenden Tabelle auswählen und einen Blick auf die TableCardinality werfen Eigentum. Es gibt noch eine weitere interessante Eigenschaft, Geschätzte Zeilengröße zur Angabe der Zeilengröße und ungefähre Einschätzung der Tabellen- bzw. Indexgröße (sofern die Tabelle nicht komprimiert ist).
Ich möchte darauf hinweisen, dass dies keine tatsächliche Anzahl von Zeilen in einer Tabelle ist, sondern Daten aus den Objektstatistiken. Diese Daten bilden jedoch die Grundlage für die Entscheidungen, die der Optimierer beim Erstellen einer Abfrage trifft.
Kontext
Der Abfrageplan speichert bemerkenswerte SET-Einstellungen, für die er erstellt wurde. Um die Einstellungen anzuzeigen, müssen Sie ein Stammelement im Plan auswählen und die Optionen festlegen erweitern Eigentum. Beispielsweise erfahren wir, ob der Plan mit dem ARITHABORT gebaut wurde Option aktiviert (Unterschied dieser Einstellung führt oft zu zwei verschiedenen Plänen und Situationen mit schlechtem Parameter-Sniffing).
Anzahl der CPUs
Wir können die Anzahl der Prozessoren abrufen, die für den Optimierer verfügbar sind. Dazu müssen wir die OptimizerHardwareDependentPropertie öffnen s -> EstimatedAvailableDegreeOfParallelism Parameter im selben Root-Element und multipliziere ihn mit 2. Wenn nur ein Prozessor verfügbar ist, muss nicht multipliziert werden.
2*2 =4, es stehen 4 CPUs zur Verfügung. Tatsächlich habe ich einen 4-Kern-Prozessor auf meinem Computer, und alle 4 Kerne stehen für den Server zur Verfügung. Diese Informationen können Ihnen dabei helfen, den Computer zu erkennen, auf dem der Plan erstellt wurde.
Version des Kardinalitätsschätzers
Ab SQL Server 2014 sind mehrere Versionen von Cardinality Estimator (RU) verfügbar. Dieser Mechanismus wirkt sich auf die meisten Entscheidungen aus, die der Optimierer bei der Auswahl eines Plans trifft. Sie können die Version von Cardinality Estimator aus CardinalityEstimationModelVersion abrufen Eigenschaft des Root-Operators.
- 0 – SQL Server <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Abfrageausführungszeit und Wartezeit
Ab SQL Server 2016 SP1 enthält der eigentliche Abfrageplan Informationen zur Ausführungszeit und Prozessorzeit. Um diese Daten abzurufen, müssen Sie QueryTimeStats erweitern -Eigenschaft im Stammelement und sehen Sie sich die Werte von CpuTime an und ElapsedTime . Wir müssen die Erfassung der Ausführungszeit nicht aktivieren oder fragen:„Wie lange wurde die Abfrage ausgeführt?“ mehr – all diese Informationen sind im Plan enthalten.
Die zweite bemerkenswerte Verbesserung sind die Top 10 der längsten Wartezeiten während der Abfrageausführung. Dazu müssen wir die WaitStats erweitern -Eigenschaft im Root-Element. Diese Ergänzung ermöglicht es, genauere Gründe für eine langsame Abfrageausführung zu erhalten, und vereinfacht die Diagnose erheblich.
Parametertypen
Die Parameterliste -Eigenschaft, die die in der Abfrage verwendeten Parameter auflistet, existierte schon vor langer Zeit im Plan. Ab SQL Server 2016 SP1 ist jedoch der Parameterdatentyp -Eigenschaft wurde der Parameterdefinition hinzugefügt. Diese Eigenschaft speichert den Datentyp des Parameters. Es kann hilfreich sein, um Probleme mit der Typkonvertierung zu verstehen.
Anzahl gelesener Zeilen und geschätzte Anzahl zu lesender Zeilen
Der Ausführungsplan enthält zwei sehr wichtige Eigenschaften, die tatsächliche Anzahl der Zeilen und die geschätzte Anzahl der Zeilen. Diese Eigenschaften enthalten Informationen über die Anzahl der vom Datenleseoperator zurückgegebenen Zeilen, aber nicht über die Anzahl der tatsächlich gelesenen Zeilen. Die Eigenschaften Number of Rows Read und Estimated Number of Rows to be Read beantworten diese Frage und ermöglichen das Abrufen der Anzahl der Zeilen, die der Server tatsächlich gelesen hat oder lesen wird. Die Eigenschaft ActualRowsRead (Anzahl der in SSMS gelesenen Zeilen) ist ab SQL Server 2012 SP3, 2014 SP2, 2016 SP1 verfügbar. Die EstimatedRowsRead (Geschätzte Anzahl zu lesender Zeilen in SSMS) ist ab SQL Server 2016 SP1 verfügbar.
IO-Statistiken und Operator-Ausführungszeit
Es gibt mehrere sehr nützliche Eigenschaften, die in SQL Server 2016, 2014 SP2 eingerichtet wurden und im eigentlichen Abfrageplan verfügbar sind. Dies sind IO-Metriken (wenn ein Operator IO hat) – Tatsächliche IO-Statistiken, CPU- und Ausführungszeitmetriken – Tatsächliche Zeitstatistiken und Speichermetriken (ab 2016 SP1, wenn ein Operator Speicher benötigt).
Die Eigenschaften umfassen die folgenden neuen Metriken, die im Fall des parallelen Plans in Threads unterteilt werden können:
- ActualElapsedms
- Tatsächliche CPUs
- Aktuelle Scans
- ActualLogicalReads
- ActualPhysicalReads
- TatsächlicheReadAheads
- ActualLobLogicalReads
- ActualLobPhysicalReads
- TatsächlicheLobReadAheads
- InputMemoryGrant
- OutputMemoryGrant
- UsedMemoryGrant
Wie Sie der obigen Liste entnehmen können, können Sie umfassende Informationen über die Ausführung eines bestimmten Operators, verbrauchte IO und Speicher abrufen. In den letzten Versionen von SSMS werden diese Metriken im Eigenschaftsfenster dargestellt. Wenn Sie eine alte Version von SSMS verwenden, können Sie sie abrufen, indem Sie plan als XML öffnen. Meiner Meinung nach gibt es jetzt alles, um Prozente nicht nach geschätzten Kosten, sondern nach tatsächlich verstrichenen Ressourcen anzuzeigen (ich habe einen Vorschlag bei Connect erstellt. Wenn Sie also die Idee mögen, stimmen Sie bitte dafür).
Informationen zu aktivierten Trace-Flags
Ablaufverfolgungsflags in SQL Server sind spezielle „Schalter“ vom standardmäßigen Serververhalten zu einem anderen Verhalten. Ab SQL Server 2014 SP2 und 2016 SP1 sind Informationen zu aktivierten Ablaufverfolgungsflags in der TraceFlags-Eigenschaft des jeweiligen Elements verfügbar. Es kann zum Zeitpunkt der Abfrageerstellung bis zu 100 gleichzeitig aktivierte Flags enthalten.
Informationen über das Überlaufen von Daten in tempdb
Einige Planoperatoren, wie z. B. Sort oder Hash Match, benötigen während der Abfrageausführung Speicher. Das Speichervolumen wird jedoch zum Zeitpunkt der Kompilierung berechnet. Aus verschiedenen Gründen (z. B. falsche Auswertung vermeintlicher Anzahl oder Zeilen) kann das Speichervolumen falsch berechnet werden. Wenn weniger Speicher zugewiesen wird, als für die Ausführung erforderlich ist, muss der Server Daten an tempdb übergeben. Es verlangsamt die Abfrageausführung. Vorsicht vor einer solchen Situation wurde in Server 2012 eingeführt, aber ab SQL Server 2012 SP3, 2014 SP2, 2016 wurden die Diagnoseinformationen erweitert und umfassen jetzt das Volumen der verschütteten Daten und gelesenen Daten. So können Sie das Problem bewerten und die richtigen Maßnahmen ergreifen.
Schlussfolgerung
Der Ausführungsplan enthält viele nützliche Informationen, der tatsächliche Abfrageplan enthält noch mehr Informationen, und der tatsächliche Abfrageplan in den letzten Versionen von SQL Server ist nur eine Fundgrube für nützliche Informationen. Dieser Artikel soll niemandem beibringen, Abfragepläne zu analysieren. Stattdessen betrachtete ich die interessantesten Planobjekte, darunter neue Objekte und alte, aber unterschätzte. Ich hoffe, dieser Artikel hilft Ihnen beim nächsten Mal, wenn Sie die Abfrageleistung analysieren müssen.
Der Artikel wurde vom Codingsight-Team mit Genehmigung des Autors übersetzt.
Nützliches Tool:
dbForge Query Builder for SQL Server – ermöglicht Benutzern das schnelle und einfache Erstellen komplexer SQL-Abfragen über eine intuitive visuelle Oberfläche ohne manuelles Schreiben von Code.
