Freigeben über

Features der intelligenten Abfrageverarbeitung im Detail

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

Dieser Artikel enthält ausführliche Beschreibungen der verschiedenen Features der intelligenten Abfrageverarbeitung (Intelligent Query Processing, IQP), Versionshinweise und weitere Details. Die Featurefamilie „Intelligente Abfrageverarbeitung“ (Intelligent Query Processing, IQP) umfasst Features mit weitreichenden Auswirkungen, die die Leistung vorhandener Workloads mit minimalem Implementierungsaufwand verbessern.

Sie können Workloads automatisch für die intelligente Abfrageverarbeitung anpassen, indem Sie den geeigneten Datenbank-Kompatibilitätsgrad für die Datenbank aktivieren. Diesen können Sie mit Transact-SQL festlegen. Zum Beispiel, um die Kompatibilitätsebene einer Datenbank auf SQL Server 2022 (16.x) festzulegen:

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

Alle IQP-Funktionen sind in Azure SQL Managed Instance und Azure SQL Database verfügbar, manchmal abhängig vom Kompatibilitätsmodus der jeweiligen Datenbank. Weitere Informationen zu den Änderungen, die mit neuen Versionen eingeführt wurden, finden Sie unter:

Adaptive Joins im Batchmodus

Gilt für: SQL Server (ab SQL Server 2017 (14.x)) und Azure SQL-Datenbank

Mit dem Feature „Adaptive Joins im Batchmodus“ wird es ermöglicht, die Wahl der Join-Methode (Hashjoin oder Join geschachtelter Schleifen) auf den Zeitpunkt nach der Überprüfung der ersten Eingabe zu verzögern, indem ein einzelner zwischengespeicherter Plan verwendet wird. Der Operator für adaptive Joins definiert einen Schwellenwert, der bestimmt, wann zu einem Plan geschachtelter Schleifen gewechselt wird. Daher kann Ihr Plan während der Ausführung dynamisch zu einer passenderen Joinstrategie wechseln.

Weitere Informationen, z. B. zum Deaktivieren adaptiver Joins ohne Änderung des Kompatibilitätsgrads, finden Sie unter Grundlegendes zu adaptiven Joins.

Verschachtelte Ausführung für MSTVFs

Gilt für: SQL Server (ab SQL Server 2017 (14.x)) und Azure SQL-Datenbank

Eine Mehrfach-Anweisungs-Tabellenwertfunktion (Multi-Statement Table-Valued Function, MSTVF) ist eine Art von benutzerdefinierter Funktion, die Parameter, mehrere T-SQL-Anweisungen und RETURN eine Tabelle akzeptieren kann.

Die verschachtelte Ausführung löst Probleme bei der Leistung von Workloads, die auf die festgelegten Kardinalitätsschätzungen von MSTVFs zurückzuführen sind. Bei der verschachtelten Ausführung verwenden Sie die tatsächliche Zeilenanzahl aus der Funktion, um besser informierte Entscheidungen zum Downstream-Abfrageplan zu treffen.

Die festgelegte Kardinalitätsschätzung von Tabellenwertfunktionen mit mehreren Anweisungen beträgt ab SQL Server 2014 (12.x) „100“ und in früheren Versionen von SQL Server „1“.

Eine verschachtelte Ausführung ändert die unidirektionale Grenze zwischen der Optimierungs- und der Ausführungsphase für eine Ausführung mit einer Abfrage. Zudem können Pläne damit auf Grundlage der überarbeiteten Kardinalitätsschätzungen angepasst werden. Wenn die Datenbank-Engine während der Optimierung auf einen Kandidaten für die verschachtelte Ausführung stößt, der MSTVFs verwendet, hält die Optimierung an, führt die entsprechende Unterstruktur aus, erfasst genaue Kardinalitätsschätzungen und setzt dann die Optimierung für nachgelagerte Operationen fort.

Die folgende Abbildung zeigt die Ausgabe einer Liveabfragestatistik, einer Teilmenge eines allgemeinen Ausführungsplans, der die Auswirkung festgelegter Kardinalitätsschätzungen von MSTVFs veranschaulicht.

Sie sehen den tatsächlichen Zeilenfluss gegenüber dem geschätzten. Es gibt drei erwähnenswerte Bereiche des Plans (von rechts nach links):

  • Der MSTVF-Table Scan hat eine festgelegte Schätzung von 100 Zeilen. In diesem Beispiel gibt es allerdings 527.597 Zeilen, die den MSTVF Table Scan durchlaufen. Dies ist an der Liveabfragestatistik 527597 von 100 der tatsächlichen Elemente von geschätzten Elemente zu erkennen – die festgelegte Schätzung liegt also deutlich zu weit unten.
  • Für den Nested Loop-Vorgang wird davon ausgegangen, dass nur 100 Zeilen von der äußeren Seite des Joins zurückgegebene werden. Aufgrund der hohen Zahl an tatsächlich von MSTVF zurückgegebenen Zeilen sollten Sie sich aber für einen komplett anderen Joinalgorithmus entscheiden.
  • Beachten Sie, dass beim Hash Match-Vorgang ein kleines Warnsymbol angezeigt wird, das in diesem Fall darauf hinweist, dass es einen Überlauf auf den Datenträger hab.

Grafik des Zeilenflusses eines Ausführungsplans im Vergleich zu den geschätzten Zeilen.

Vergleichen Sie den vorherigen Plan mit dem tatsächlich generierten Plan mit aktivierter verschachtelter Ausführung:

Grafik des verschachtelten Ausführungsplans.

  • Beachten Sie, dass der MSTVF-Table Scan jetzt die genaue Kardinalitätsschätzung widerspiegelt. Beachten Sie auch die Neuanordnung des Table Scans und der anderen Vorgänge.
  • Bei Joinalgorithmen haben Sie von einem Nested Loop-Vorgang zu einem Hash Match-Vorgang gewechselt, was für die vorhandene Zahl an Zeilen optimaler ist.
  • Beachten Sie auch, dass es keine Überlaufwarnungen mehr gibt, da mehr Speicherplatz auf Grundlage der tatsächlichen Zeilenzahl, die den MSTVF-Table Scan durchläuft, zugewiesen wird.

Zulässige Anweisungen für verschachtelte Ausführungen

Verweisanweisungen von MSTVF in verschachtelten Ausführungen müssen aktuell schreibgeschützt sein und dürfen nicht Teil eines Datenmodifizierungsvorgangs sein. MSTVFs eignen sich nur für die verschachtelte Ausführung, wenn Sie Laufzeitkonstanten verwenden.

Vorteile der verschachtelten Ausführung

Allgemein gilt: Je höher der Unterschied zwischen der geschätzten und tatsächlichen Zeilenzahl in Verbindung mit der Zahl von Downstreamplanvorgängen ist, desto mehr wird die Leistung beeinträchtigt.

Allgemein profitieren Abfragen von der verschachtelten Ausführung, die:

  • eine große Diskrepanz zwischen der geschätzten und tatsächlichen Zeilenzahl für das temporäre Resultset aufweisen (in diesem Fall MSTVF);
  • und in denen die Abfrage empfindlich ist, was Änderungen der Größe des temporären Ergebnisses angeht. Dies geschieht typischerweise, wenn es eine komplexe Struktur über der Unterstruktur im Abfrageplan gibt. Ein einfaches SELECT * einer MSTVF profitiert nicht von einer verschachtelten Ausführung.

Aufwand der verschachtelten Ausführung

Der Aufwand sollte sehr gering oder nicht vorhanden sein. MSTVFs wurden bereits vor der Einführung der verschachtelten Ausführung materialisiert. Der Unterschied besteht jedoch darin, dass wir jetzt eine aufgeschobene Optimierung zulassen und dann die Kardinalitätsschätzung der materialisierten Zeilenmenge verwenden. Genauso wie mit allen Änderungen, die sich auf Pläne auswirken, können sich einige Pläne so ändern, dass Sie einen schlechteren Plan für die Abfrage erhalten, auch wenn Sie eine bessere Kardinalität der Unterstruktur haben. Dies können Sie z. B. verhindern, indem Sie den Kompatibilitätsgrad wiederherstellen oder den Abfragespeicher verwenden, um das Verwenden der nicht rückläufigen Version des Plans zu erzwingen.

Verschachtelte Ausführung und nachfolgende Ausführungen

Sobald ein verschachtelter Ausführungsplan zwischengespeichert wurde, wird der Plan mit den überarbeiteten Schätzungen der ersten Ausführung für nachfolgende Ausführungen verwendet, ohne dass die verschachtelte Ausführung neu instantiiert werden muss.

Verfolgen der Aktivität von verschachtelten Ausführungen

Sie können sich Verwendungsattribute im Ausführungsplan der Abfrage anschauen:

Ausführungsplanattribut Beschreibung
ContainsInterleavedExecutionCandidates Gilt für den Knoten QueryPlan. Wenn dieser true lautet, gibt dieser an, dass der Plan mögliche Kandidaten für die überlappende Ausführung enthält.
IsInterleavedExecuted Das Attribut des Elements RuntimeInformation befindet sich für den Knoten „TVF“ unter „RelOp“. Wenn es true entspricht, wurde der Vorgang im Zuge einer überlappenden Ausführung materialisiert.

Sie können überlappende Ausführungen auch mit den folgenden erweiterten Ereignisse nachverfolgen:

XEvent Beschreibung
interleaved_exec_status Dieses Ereignis wird ausgelöst, wenn eine verschachtelte Ausführung durchgeführt wird.
interleaved_exec_stats_update Dieses Ereignis beschreibt die von der verschachtelten Ausführung aktualisierten Kardinalitätsschätzungen.
Interleaved_exec_disabled_reason Dieses Ereignis wird ausgelöst, wenn eine Abfrage mit einem möglichen Kandidaten für eine verschachtelte Ausführung nicht verschachtelt ausgeführt wird.

Eine Abfrage muss ausgeführt werden, damit die verschachtelte Ausführung die Kardinalitätsschätzungen für MSTVF überarbeiten kann. Allerdings zeigt der geschätzte Ausführungsplan immer noch an, wenn es Kandidaten für eine überlappende Ausführung gibt. Dies macht er mithilfe des showplan-Attributs ContainsInterleavedExecutionCandidates.

Zwischenspeichern der verschachtelte Ausführung

Wenn ein Plan aus dem Cache gelöscht oder entfernt wird, kommt es bei der Abfrageausführung zu einer neuen Kompilierung mit der verschachtelten Ausführung. Eine Anweisung, die über OPTION (RECOMPILE) einen neuen Plan mit verschachtelter Ausführung erstellt und nicht im Cache speichert.

Geschachtelte Ausführung und Interoperabilität des Abfragespeichers

Pläne mit der verschachtelten Ausführung können erzwungen werden. Der Plan ist die Version mit angepassten Kardinalitätsschätzungen auf Grundlage der ersten Ausführung.

Deaktivieren der verschachtelte Ausführung ohne Änderung des Kompatibilitätsgrads

Geschachtelte Ausführung kann im Datenbank- oder Anweisungsbereich deaktiviert werden, während der Datenbankkompatibilitätsgrad weiterhin bei 140 und höher bleibt. Um geschachtelte Ausführung für alle Abfrageausführungen zu deaktivieren, die aus der Datenbank stammen, führen Sie die folgende Anweisung im Kontext der betroffenen Datenbank aus:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

Ist diese Einstellung aktiviert, wird sie in sys.database_scoped_configurations als aktiviert aufgeführt. Um geschachtelte Ausführung für alle Abfrageausführungen wieder zu aktivieren, die aus der Datenbank stammen, führen Sie die folgende Anweisung im Kontext der betroffenen Datenbank aus:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

Sie können adaptive Joins auch für eine verschachtelte Ausführung für eine bestimmte Abfrage deaktivieren, indem Sie DISABLE_INTERLEAVED_EXECUTION_TVF als USE HINT-Abfragehinweis festlegen. Zum Beispiel:

SELECT [fo].[Order Key], [fo].[Quantity], [foo].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession',
                            '1-01-2013',
                            '10-15-2014') AS [foo] ON [fo].[Order Key] = [foo].[Order Key]
                            AND [fo].[City Key] = [foo].[City Key]
                            AND [fo].[Customer Key] = [foo].[Customer Key]
                            AND [fo].[Stock Item Key] = [foo].[Stock Item Key]
                            AND [fo].[Order Date Key] = [foo].[Order Date Key]
                            AND [fo].[Picked Date Key] = [foo].[Picked Date Key]
                            AND [fo].[Salesperson Key] = [foo].[Salesperson Key]
                            AND [fo].[Picker Key] = [foo].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

Ein USE HINT-Abfragehinweis hat Vorrang vor einer datenbankweit gültigen Konfiguration oder einer Ablaufverfolgungsflageinstellung.

Inlining benutzerdefinierter Skalarfunktionen

Gilt für: SQL Server (ab SQL Server 2019 (15.x)) und Azure SQL-Datenbank

Das skalare UDF-Inlining wandelt skalare UDFs automatisch in relationale Ausdrücke um. Diese werden in die aufrufende SQL-Abfrage eingebettet. Diese Transformation verbessert die Leistung von Workloads, die skalare UDFs nutzen. Skalares UDF-Inlining ermöglicht eine kostenbasierte Optimierung der Vorgänge innerhalb von UDFs. Die Ergebnisse sind effiziente, mengenorientierte und parallele statt ineffiziente, iterative, serielle Ausführungspläne. Dieses Feature ist standardmäßig unter dem Datenbank-Kompatibilitätsgrad 150 oder höher aktiviert.

Weitere Informationen finden Sie unter Inlining benutzerdefinierter Skalarfunktionen.

Verzögerte Kompilierung von Tabellenvariablen

Gilt für: SQL Server (ab SQL Server 2019 (15.x)) und Azure SQL-Datenbank

Die verzögerte Kompilierung von Tabellenvariablen verbessert die Qualität des Abfrageplans und die Gesamtleistung für Abfragen mit Verweisen auf Tabellenvariablen. Während der Optimierung und der ersten Plan-Kompilierung propagiert diese Funktion Kardinalitätsschätzungen, die auf tatsächlichen Tabellenvariablen-Zeilenzahlen basieren. Diese Informationen zur genauen Zeilenzahl werden dann zur Optimierung der nachgelagerten Planvorgänge verwendet.

Bei der verzögerten Kompilierung von Tabellenvariablen wird die Kompilierung einer Anweisung, die auf eine Tabellenvariable verweist, bis zur ersten tatsächlichen Ausführung der Anweisung verzögert. Dieses Verhalten der verzögerten Kompilierung ist identisch mit dem von temporären Tabellen. Diese Änderung führt dazu, dass anstelle des ursprünglichen einreihigen Schätzwertes die tatsächliche Kardinalität verwendet wird.

Aktivieren Sie den Datenbank-Kompatibilitätsgrad 150 oder höher für die Datenbank, mit der Sie beim Ausführen der Abfrage verbunden sind, um die verzögerten Kompilierung von Tabellenvariablen zu aktivieren.

Die verzögerte Kompilierung von Tabellenvariablen führt nicht zu Änderungen an anderen Merkmalen von Tabellenvariablen. Beispielsweise wird durch dieses Feature keine Spaltenstatistik zu Tabellenvariablen hinzugefügt.

Die verzögerte Kompilierung von Tabellenvariablen führt nicht zu einer häufigeren Neukompilierung. Stattdessen wird der Zeitpunkt der ersten Kompilierung verschoben. Der resultierende zwischengespeicherte Plan wird basierend auf der anfänglichen Zeilenanzahl für die verzögerte Kompilierung von Tabellenvariablen generiert. Der zwischengespeicherte Plan wird von nachfolgenden Abfragen wiederverwendet. Es wird solange wiederverwendet, bis der Plan entfernt oder erneut kompiliert wird.

Die Zeilenanzahl für Tabellenvariablen, die für die anfängliche Plankompilierung verwendet wird, stellt einen typischen Wert dar, der von einem geschätzten Festwert für die Zeilenanzahl abweichen kann. Bei Abweichungen profitieren Downstreamvorgänge. Weicht die Zeilenanzahl für Tabellenvariablen für alle durchgeführten Ausführungen erheblich ab, wird die Leistung durch dieses Feature möglicherweise nicht verbessert.

Deaktivieren der verzögerten Kompilierung von Tabellenvariablen ohne Änderung des Kompatibilitätsgrads

Deaktivieren Sie die verzögerte Kompilierung von Tabellenvariablen im Datenbank- oder Anweisungsbereich, während Sie den Datenbankkompatibilitätsgrad bei 150 und höher beibehalten. Um die verzögerte Kompilierung von Tabellenvariablen für alle Abfrageausführungen zu deaktivieren, die aus der Datenbank stammen, führen Sie das folgende Beispiel im Kontext der betroffenen Datenbank aus:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Um die verzögerte Kompilierung von Tabellenvariablen für alle Abfrageausführungen, die aus der Datenbank stammen, erneut zu aktivieren, führen Sie das folgende Beispiel im Kontext der betroffenen Datenbank aus:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Sie können die verzögerte Kompilierung von Tabellenvariablen auch für eine bestimmte Abfrage deaktivieren, indem Sie DISABLE_DEFERRED_COMPILATION_TV als USE HINT-Abfragehinweis zuweisen. Zum Beispiel:

DECLARE @LINEITEMS TABLE 
    (L_OrderKey INT NOT NULL,
     L_Quantity INT NOT NULL
    );

INSERT @LINEITEMS
SELECT L_OrderKey, L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
    O_CustKey,
    O_OrderStatus,
    L_QUANTITY
FROM    
    ORDERS,
    @LINEITEMS
WHERE    O_ORDERKEY    =    L_ORDERKEY
    AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

Optimierung des Parameterempfindlichkeitsplans

Gilt für: SQL Server (ab SQL Server 2022 (16.x))

Die Optimierung des Parameterempfindlichkeitsplans (Parameter Sensitivity Plan, PSP) ist Teil der intelligenten Abfrageverarbeitungsfeatures. Sie wurde für Szenarien entwickelt, in denen ein einzelner zwischengespeicherter Plan für eine parametrisierte Abfrage nicht für alle möglichen eingehenden Parameterwerte optimal ist. Dies ist bei uneinheitlichen Datenverteilungen der Fall.

Geschätzte Abfrageverarbeitung

Die geschätzte Abfrageverarbeitung ist eine neue Featurefamilie. Sie stellt Aggregationen über große Datasets hinweg bereit, bei denen die Reaktionsfähigkeit wichtiger ist als die absolute Präzision. Ein Beispiel ist die Berechnung eines COUNT(DISTINCT()) über 10 Milliarden Zeilen für die Anzeige auf einem Dashboard. In diesem Fall ist absolute Genauigkeit nicht wichtig, aber die Reaktionsfähigkeit ist es jedoch.

Geschätzte eindeutige Anzahl

Gilt für: SQL Server (ab SQL Server 2019 (15.x)) und Azure SQL-Datenbank

Diese neue APPROX_COUNT_DISTINCT-Aggregatfunktion gibt die ungefähre Anzahl von eindeutigen Ungleich-Null-Werten in einer Gruppe zurück.

Dieses Feature ist ab SQL Server 2019 (15.x) unabhängig von der Kompatibilitätsstufe verfügbar.

Weitere Informationen finden Sie unter APPROX_COUNT_DISTINCT (Transact-SQL).

Angenähertes Perzentil

Gilt für: SQL Server (ab SQL Server 2022 (16.x)) und Azure SQL-Datenbank

Berechnen Sie mithilfe dieser Aggregatfunktionen für angenäherte Perzentile schnell und mit annehmbaren rangbasierten Fehlergrenzen Perzentile für ein großes Dataset, um schnell Entscheidungen zu treffen.

Weitere Informationen finden Sie unter APPROX_PERCENTILE_DISC (Transact-SQL) und APPROX_PERCENTILE_CONT (Transact-SQL)

Batchmodus bei Rowstore

Gilt für: SQL Server (ab SQL Server 2019 (15.x)) und Azure SQL-Datenbank

Batchmodus bei Rowstore ermöglicht die Ausführung im Batchmodus für Analyseworkloads, die keine Columnstore-Indizes erfordern. Dieses Feature unterstützt die Ausführung im Batchmodus und Bitmapfilter für On-Disk-Heaps und B-Struktur-Indizes. Batchmodus bei Rowstore ermöglicht die Unterstützung aller vorhandenen batchmodusfähigen Operatoren.

Hinweis

In der SQL Server-Dokumentation wird der Begriff „B-Struktur“ im Allgemeinen in Bezug auf Indizes verwendet. In Zeilenspeicherindizes implementiert SQL Server eine B+-Struktur. Dies gilt nicht für Columnstore-Indizes oder In-Memory-Datenspeicher. Weitere Informationen finden Sie im Leitfaden zur Architektur und zum Entwerfen von SQL Server- und Azure SQL-Indizes.

Batchmodusausführung im Überblick

SQL Server 2012 (11.x) hat ein neues Feature zur Beschleunigung analytischer Workloads eingeführt: Columnstore-Indizes. Die Anwendungsfälle und die Leistung von Columnstore-Indizes wurden in jeder nachfolgenden Version von SQL Server verbessert. Das Erstellen von Columnstore-Indizes auf Tabellen kann die Leistung für analytische Workloads verbessern. Es gibt jedoch zwei miteinander zusammenhängende, aber unterschiedliche Gruppen von Technologien:

  • Columnstore-Indizes erlauben Analyseabfragen nur den Zugriff auf die Daten in den Spalten, die sie benötigen. Die Seitenkomprimierung im Spaltenspeicherformat ist ebenfalls effektiver als die Komprimierung in traditionellen Rowstore-Indizes.
  • Mit der Verarbeitung im Batchmodus verarbeiten Abfrageoperatoren Daten effizienter. Die Verarbeitung erfolgt für ein Batch an Zeilen und nicht für jede Zeile einzeln. Zahlreiche weitere Verbesserungen der Skalierbarkeit sind an die Batchmodusverarbeitung gebunden. Weitere Informationen zum Batchmodus finden Sie unter Ausführungsmodi.

Die zwei Featuregruppen verbessern zusammen die E/A- und CPU-Auslastung:

  • Durch Columnstore-Indizes passen mehr Daten in den Speicher. Dadurch wird die E/A-Arbeitsauslastung reduziert.
  • Die Batchmodusverarbeitung nutzt die CPU effizienter.

Wann immer möglich, machen sich die beiden Technologien gegenseitig zu Nutze. So können Batchmodusaggregate z.B. als Teil eines Columnstore-Indexes ausgewertet werden. Außerdem werden komprimierte Columnstore-Daten mit der Lauflängencodierung wesentlich effizienter mit Joins im Batchmodus und Batchmodusaggregaten verarbeitet.

Es ist jedoch wichtig, zu berücksichtigen, dass die beiden Merkmale unabhängig voneinander sind:

  • Sie können Zeilenmoduspläne erhalten, die Columnstore-Indizes verwenden.
  • Sie können Batchmoduspläne erhalten, die nur Rowstore-Indizes verwenden.

Sie erhalten in der Regel die besten Ergebnisse, wenn Sie die beiden Features zusammen verwenden. Vor SQL Server 2019 (15.x) betrachtete der SQL Server-Abfrageoptimierer die Verarbeitung im Batchmodus nur für Abfragen, die mindestens eine Tabelle mit einem Columnstore-Index betreffen.

Columnstore-Indizes sind für einige Anwendungen möglicherweise nicht geeignet. Eine Anwendung kann ein anderes Feature verwenden, das nicht von Columnstore-Indizes unterstützt wird. Direkte Änderungen sind beispielsweise nicht mit der Columnstore-Komprimierung kompatibel. Daher werden Auslöser in Tabellen mit gruppierten Columnstore-Indizes nicht unterstützt. Noch wichtiger ist, dass DELETE- und UPDATE-Anweisungen durch Columnstore-Indizes aufwändiger werden.

Für einige hybride Transaktions-/Analyseworkloads überwiegt der Mehraufwand bei Transaktionsworkloads die Vorteile der Verwendung von Columnstore-Indizes für Analyseabfragen. Solche Szenarios können von einer verbesserten CPU-Auslastung profitieren, indem nur die Batchmodusverarbeitung genutzt wird. Aus diesem Grund berücksichtigt das Feature „Batchmodus bei Rowstore“ den Batchmodus für alle Abfragen, unabhängig davon, welche Art von Indizes beteiligt sind.

Workloads, die vom Batchmodus auf Rowstore profitieren können

Die folgenden Workloads können vom Batchmodus auf Rowstore profitieren:

  • Ein signifikanten Teil der Workload besteht aus analytischen Abfragen. Normalerweise verwenden diese Abfragen Operatoren wie Joins oder Aggregate, die Hunderttausende von Zeilen oder mehr verarbeiten.
  • Die Workload ist CPU-gebunden. Wenn der Engpass E/A ist, wird weiterhin empfohlen, dass Sie nach Möglichkeit einen Columnstore-Index in Betracht ziehen.
  • Das Erstellen eines Columnstore-Index fügt dem transaktionalen Teil Ihrer Workload zu viel Mehraufwand hinzu. Oder es kann kein Columnstore-Index erstellt werden, da Ihre Anwendung von einem Feature abhängt, das bei Columnstore-Indizes noch nicht unterstützt wird.

Hinweis

Batchmodus bei Rowstore kann nur bei der Verringerung des CPU-Verbrauchs helfen. Wenn Ihr Engpass E/A-bezogen ist und Daten nicht bereits zwischengespeichert werden („kalter“ Cache), verbessert Batchmodus bei Rowstore die verstrichene Abfragezeit nicht. Ähnlich gilt, dass eine Leistungsverbesserung unwahrscheinlich ist, wenn auf dem Computer nicht genügend Arbeitsspeicher zum Zwischenspeichern aller Daten vorhanden ist.

Welche Änderungen mit dem Batchmodus auf Rowstore verbunden sind

Der Batch-Modus auf Rowstore erfordert eine Datenbank mit Kompatibilitätsstufe 150.

Selbst wenn eine Abfrage auf keine Tabellen mit Columnstore-Indizes zugreift, verwendet der Abfrageprozessor Heuristiken, um zu entscheiden, ob der Batchmodus in Betracht gezogen werden soll. Die Heuristik umfasst diese Überprüfungen:

  1. Ein erstes Überprüfen der Tabellengrößen, verwendeten Operatoren und geschätzten Kardinalitäten in der Eingabeabfrage.
  2. Weitere Prüfpunkte kommen hinzu, wenn der Abfrageoptimierer neue, kostengünstigere Pläne für die Abfrage entdeckt. Wenn diese alternativen Pläne keine signifikante Verwendung des Batchmodus aufweisen, beendet der Optimierer die Untersuchung von Batchmodusalternativen.

Wenn der Batch-modus bei Rowstow verwendet wird, sehen Sie den tatsächlichen Ausführungsmodus als Batchmodus im Abfrageplan. Der Scan-Operator verwendet den Batchmodus für On-Disk-Heaps und B-Struktur-Indizes. Diese Überprüfung im Batchmodus kann Batchmodus-Bitmapfilter auswerten. Vielleicht finden Sie auch andere Batchmodusoperatoren im Plan. Beispielsweise Hashjoins, hashbasierte Aggregate, Sortierungen, Fensteraggregate, Filter, Verkettung und Skalarwertberechnungs-Operatoren.

Hinweise

Abfragepläne verwenden nicht immer den Batchmodus. Der Abfrageoptimierer entscheidet möglicherweise, dass der Batchmodus für die Abfrage nicht sinnvoll ist.

Der Suchbereich des Abfrageoptimierers ändert sich. Wenn Sie also einen Zeilenmodusplan erhalten, ist er möglicherweise nicht derselbe wie der Plan, den Sie in einem niedrigeren Kompatibilitätsgrad erhalten. Und wenn Sie einen Batchmodusplan erhalten, ist er möglicherweise nicht derselbe wie der Plan, den Sie mit einem Columnstore-Index erhalten.

Aufgrund des neuen Batchmodus-Rowstore-Scans können Pläne sich auch für Abfragen ändern, die Columnstore- und Rowstore-Indizes mischen.

Aktuell bestehen folgende Einschränkungen für den neuen Batchmodus bei Rowstorescans:

  • Er funktioniert nicht bei In-Memory-OLTP-Tabellen und kann ausschließlich für Indizes verwendet werden, die sich auf Datenträgerheaps oder in B-Strukturen befinden.
  • Er funktioniert auch nicht, wenn eine LOB-Spalte abgerufen oder gefiltert wird. Diese Einschränkung betrifft Spaltensätze mit geringer Dichte und XML-Spalten.

Es gibt Abfragen, für die der Batchmodus auch bei Columnstore-Indizes nicht verwendet wird. Beispiele sind Abfragen, die Cursor enthalten. Dieselben Ausschlüsse gelten auch für den Batchmodus bei Rowstore.

Konfigurieren des Batchmodus bei Rowstore

Die BATCH_MODE_ON_ROWSTORE-Datenbankbereichskonfiguration ist standardmäßig aktiviert.

Sie können den Batch-Modus in Rowstore deaktivieren, ohne die Kompatibilitätsebene der Datenbank zu ändern:

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

Sie können den Batchmodus bei Rowstore über die datenbankweite Konfiguration deaktivieren. Sie können die Einstellung auf Abfrageebene jedoch immer noch überschreiben, indem Sie den Abfragehinweis ALLOW_BATCH_MODE verwenden. Im folgenden Beispiel wird der Batchmodus bei Rowstore aktiviert, auch wenn die Funktion über die datenbankweite Konfiguration deaktiviert ist:

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

Sie können den Batchmodus bei Rowstore auch mit dem Abfragehinweis DISALLOW_BATCH_MODE für eine bestimmte Abfrage deaktivieren. Siehe folgendes Beispiel:

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

Feedbackfeatures für die Abfrageverarbeitung

Die Feedback-Features zur Abfrageverarbeitung gehören zur Familie der Funktionen für die intelligente Anfrageverarbeitung.

Das Feedback zur Abfrageverarbeitung ist ein Prozess, bei dem der Abfrageprozessor in SQL Server, Azure SQL-Datenbank und Azure SQL verwaltete Instanz historische Daten zur Ausführung einer Abfrage verwendet, um zu entscheiden, ob die Abfrage möglicherweise Hilfe von einer oder mehreren Änderungen an der Art und Weise erhält, wie sie kompiliert und ausgeführt wird. Die Leistungsdaten werden im Abfragespeicher gesammelt, mit verschiedenen Vorschlägen zur Verbesserung der Abfrageausführung. Bei erfolgreicher Ausführung speichern wir diese Änderungen am Datenträger im Arbeitsspeicher und/oder im Abfragespeicher für die zukünftige Verwendung. Wenn die Vorschläge nicht zu einer ausreichenden Verbesserung führen, werden sie verworfen, und die Abfrage wird ohne dieses Feedback weiterhin ausgeführt.

Informationen darüber, welche Feedback-Funktionen für die Abfrageverarbeitung in den verschiedenen Versionen von SQL Server oder in Azure SQL Database oder Azure SQL Managed Instance verfügbar sind, finden Sie unter Intelligente Abfrageverarbeitung in SQL-Datenbanken oder in den folgenden Artikeln für jede Feedback-Funktion.

Feedback zur Speicherzuweisung

Das Feedback zur Speicherzuweisung wurde in Wellen in den letzten Hauptversionen von SQL Server eingeführt.

Feedback zur Speicherzuweisung im Batchmodus

Informationen über das Feedback der Speicherzuweisung im Batch-Modus finden Sie unter Feedback der Speicherzuweisung im Batch-Modus.

Feedback zur Speicherzuweisung im Zeilenmodus

Informationen über das Feedback der Speicherzuweisung im Zeilen-Modus finden Sie unter Feedback der Speicherzuweisung im Zeilen-Modus.

Feedback zur Speicherzuweisung im Perzentil- und Persistenzmodus

Informationen über das Feedback zur Speicherzuweisung im Perzentil- und Persistenzmodus finden Sie unter Feedback zur Speicherzuweisung im Perzentil- und Persistenzmodus.

Feedback zum Grad der Parallelität

Informationen zum DOP-Feedback finden Sie unter Feedback zum Grad an Parallelität (DOP).

Feedback zur Kardinalitätsschätzung (CE)

Informationen zum CE-Feedback finden Sie im Feedback zur Kardinalitätsschätzung (Cardinality Estimation, CE).

Erzwingen des optimierten Plans mit dem Abfragespeicher

Informationen zu optimierten Planzwingen mit Abfragespeicher finden Sie unter Optimierter Planzwingen mit Abfragespeicher.

Zugehöriger Inhalt