Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Vergleichen Sie Ausführungspläne in SQL Server

Der Datenbankadministrator ist immer bemüht, die SQL Server-Abfrageleistung zu optimieren. Der erste Schritt beim Optimieren der Abfrageleistung besteht darin, den Ausführungsplan einer Abfrage zu analysieren. Unter bestimmten Bedingungen kann der SQL Server-Abfrageoptimierer unterschiedliche Ausführungspläne erstellen. An dieser Stelle möchte ich einige Anmerkungen zum SQL Server Query Optimizer hinzufügen. Der SQL Server-Abfrageoptimierer ist ein kostenbasierter Optimierer, der Ausführungspläne analysiert und den optimalen Ausführungsplan für eine Abfrage bestimmt. Das entscheidende Schlüsselwort für den SQL Server Query Optimizer ist ein optimaler Ausführungsplan, der nicht unbedingt der beste Ausführungsplan ist. Wenn der SQL Server-Abfrageoptimierer versucht, den besten Ausführungsplan für jede Abfrage zu ermitteln, nimmt dies daher zusätzliche Zeit in Anspruch und beeinträchtigt die Leistung der SQL Server-Engine. In SQL Server 2016 hat Microsoft SQL Server Management Studio eine neue Funktion namens Showplan vergleichen hinzugefügt. Diese Funktion ermöglicht es uns, zwei verschiedene Ausführungspläne zu vergleichen. Gleichzeitig können wir diese Option offline verwenden, was bedeutet, dass wir die SQL Server-Instanz nicht verbinden müssen. Stellen Sie sich vor, Sie schreiben eine Abfrage und diese Abfrage funktioniert in der TEST-Umgebung gut, aber in PROD (Produktionsumgebung) sehr schlecht. Um dieses Problem zu lösen, müssen wir Ausführungspläne vergleichen. Vor dieser Funktion haben wir zwei SQL Server Management Studios geöffnet und Ausführungspläne nebeneinander gebracht, aber diese Methode war sehr umständlich.

Wie vergleiche ich zwei Ausführungspläne?

In dieser Demonstration verwenden wir die AdventureWorks-Datenbank und vergleichen zwei Ausführungspläne mit unterschiedlichen Kardinalitätsschätzungsmodellversionen und erkennen diesen Unterschied mit Showplan vergleichen.

Zunächst öffnen wir ein neues Abfragefenster in SQL Server Management Studio und klicken auf Aktuellen Ausführungsplan einschließen und führen Sie dann die folgende Abfrage aus.

SELECT 
        soh.[SalesPersonID]
        ,p.[FirstName] + ' ' + COALESCE(p.[MiddleName], '') + ' ' + p.[LastName] AS [FullName]
        ,e.[JobTitle]
        ,st.[Name] AS [SalesTerritory]
        ,soh.[SubTotal]
        ,YEAR(DATEADD(m, 6, soh.[OrderDate])) AS [FiscalYear] 
    FROM [Sales].[SalesPerson] sp 
        INNER JOIN [Sales].[SalesOrderHeader] soh 
        ON sp.[BusinessEntityID] = soh.[SalesPersonID]
        INNER JOIN [Sales].[SalesTerritory] st 
        ON sp.[TerritoryID] = st.[TerritoryID] 
        INNER JOIN [HumanResources].[Employee] e 
        ON soh.[SalesPersonID] = e.[BusinessEntityID] 
		INNER JOIN [Person].[Person] p
		ON p.[BusinessEntityID] = sp.[BusinessEntityID]

In diesem Schritt speichern wir unseren ersten Ausführungsplan. Klicken Sie mit der rechten Maustaste auf eine beliebige Stelle im Ausführungsplan und klicken Sie auf Ausführungsplan speichern unter und speichern Sie den Ausführungsplan als ExecutionPlan_CE140.sqlplan.

Jetzt öffnen wir eine neue Abfrageregisterkarte in SQL Server Management Studio und führen die folgende Abfrage aus. In dieser Abfrage fügen wir am Ende der Abfrage den Abfragehinweis FORCE_LEGACY_CARDINALITY_ESTIMATION hinzu, der die Verwendung einer älteren Version des Kardinalitätsschätzungsmodells erzwingt.
Die Aufgabe der Kardinalitätsschätzung soll vorhersagen, wie viele Zeilen unsere Abfrage zurückgeben wird.

SELECT 
        soh.[SalesPersonID]
        ,p.[FirstName] + ' ' + COALESCE(p.[MiddleName], '') + ' ' + p.[LastName] AS [FullName]
        ,e.[JobTitle]
        ,st.[Name] AS [SalesTerritory]
        ,soh.[SubTotal]
        ,YEAR(DATEADD(m, 6, soh.[OrderDate])) AS [FiscalYear] 
    FROM [Sales].[SalesPerson] sp 
        INNER JOIN [Sales].[SalesOrderHeader] soh 
        ON sp.[BusinessEntityID] = soh.[SalesPersonID]
        INNER JOIN [Sales].[SalesTerritory] st 
        ON sp.[TerritoryID] = st.[TerritoryID] 
        INNER JOIN [HumanResources].[Employee] e 
        ON soh.[SalesPersonID] = e.[BusinessEntityID] 
INNER JOIN [Person].[Person] p
	ON p.[BusinessEntityID] = sp.[BusinessEntityID]
	OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));

Wir klicken auf Showplan vergleichen und wählen Sie den vorherigen Ausführungsplan aus, der als ExecutionPlan_CE140.sqlplan gespeichert wurde.

Die folgende Abbildung zeigt den ersten Bildschirm des SQL Server-Ausführungsvergleichsplans, und rosa hervorgehobene Bereiche definieren ähnliche Vorgänge.

Wenn wir im Ausführungsplan unten oder oben auf einen beliebigen Operator klicken, hebt SQL Server Management Studio andere ähnliche Operatoren hervor. Auf der rechten Seite des Panels finden Sie Eigenschaften und Vergleichsdetails von Eigenschaften.

In diesem Schritt ändern wir die ShowPlan-Analyseoptionen und markieren den nicht übereinstimmenden Operator. Unten auf dem Bildschirm sehen wir die Showplan-Analyse Tafel. Wenn wir Ähnliche Vorgänge hervorheben deaktivieren und wählen Sie Operatoren hervorheben, die nicht mit ähnlichen Segmenten übereinstimmen SQL Server Management Studio hebt den nicht übereinstimmenden Operator hervor. Klicken Sie danach auf Operatoren auswählen im unteren und oberen Ausführungsplan im Panel. SQL Server Management Studio vergleicht die Eigenschaften der ausgewählten Operatoren und fügt den nicht identischen Werten Ungleichheitszeichen hinzu.

Wenn wir diesen Bildschirm genauer analysieren, ist das erste, was die Kardinalitätsschätzungsmodellversion ist Unterschied. Die erste Abfrageversion ist 70 und die zweite 140. Dieser Unterschied wirkt sich auf die Geschätzte Anzahl an Zeilen aus . Der Hauptgrund für die unterschiedliche Geschätzte Anzahl an Zeilen ist eine andere Version der Kardinalitätsschätzung. Daher wirkt sich die Kardinalitätsschätzungsversion direkt auf die geschätzten Metriken der Abfrage aus. Für diesen Abfragevergleich können wir schlussfolgern, dass die Abfrage mit der Version 140 der Kardinalitätsschätzung besser abschneidet, da die geschätzte Zeilenanzahl nahe an der tatsächlichen Zeilenanzahl liegt . Dieser Fall kann anhand der folgenden Tabelle verdeutlicht werden.

[Tabellen-ID=50 /]

Wenn wir Ausführungspläne nebeneinander auf demselben Bildschirm sehen möchten, können wir auf Toggle Splitter Orientation klicken .

Jetzt werden wir eine weitere Demonstration machen. Wir werden uns die folgende Abfrage ansehen und Ausführungspläne vor und nach der Indexerstellung vergleichen.
Wenn wir uns den folgenden Abfrageausführungsplan ansehen, wird empfohlen, einen nicht geclusterten Index zu erstellen.

SELECT [CarrierTrackingNumber] 
FROM [Sales].[SalesOrderDetail] WHERE [SalesOrderDetailID]=12

Wir werden den empfohlenen Index anwenden und dieselbe Abfrage erneut ausführen.

CREATE NONCLUSTERED INDEX Index_NC
ON [Sales].[SalesOrderDetail] ([SalesOrderDetailID])
GO
SELECT [CarrierTrackingNumber] 
FROM [Sales].[SalesOrderDetail] WHERE [SalesOrderDetailID]=12

In diesem letzten Schritt vergleichen wir die Ausführungspläne.

Im obigen Bild können wir mehrere Informationen zu Ausführungsplänen erhalten. Aber der Hauptunterschied ist die logische Operation Feld. Eine davon ist Indexsuche und ein weiterer ist Index Scan und diese Betriebsunterscheidung führt zu unterschiedlichen geschätzten und tatsächlichen Metrikwerten. Zuletzt ist der Index Seek-Operator leistungsfähiger als der Index Scan-Operator.

Schlussfolgerungen

Wie wir im Artikel erwähnt haben, bietet die Showplan-Vergleichsfunktion Datenbankentwicklern oder -administratoren einige Vorteile. Einige davon können gezählt werden als:

  • Einfacher Vergleich zweier Ausführungspläne.
  • Einfache Erkennung von Problemen mit der Abfrageleistung in verschiedenen SQL Server-Versionen.
  • Einfache Erkennung von Problemen mit der Abfrageleistung in verschiedenen Umgebungen.
  • Verdeutlicht einfach Ausführungsplanänderungen vor und nach der Indexerstellung.

Referenzen

  • Kardinalitätsschätzung (SQL Server)
  • Leitfaden zur Architektur der Abfrageverarbeitung