Intelligente Abfrageverarbeitungsfeatures im Detail

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance

Dieser Artikel enthält ausführliche Beschreibungen verschiedener intelligenter Abfrageverarbeitungsfeatures (IQP), Anmerkungen zur Version 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. Um beispielsweise die Kompatibilitätsstufe einer Datenbank auf SQL Server 2022 (16.x) festzulegen:

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

Alle IQP-Features sind in Azure SQL verwaltete Instanz und Azure SQL-Datenbank verfügbar, manchmal abhängig vom Kompatibilitätsmodus jeder Datenbank. Weitere Informationen zu Änderungen, die mit neuen Versionen eingeführt wurden, finden Sie unter:

• Neues in SQL Server 2017
• Neuerungen in SQL Server 2019
• Neuerungen in SQL Server 2022

Adaptive Joins im Batchmodus

Gilt für: SQL Server (ab SQL Server 2017 (14.x)), 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)), Azure SQL-Datenbank

Eine multi-anweisungstabellenwertige Funktion (MSTVF) ist eine Art benutzerdefinierter Funktion, die Parameter akzeptieren, mehrere T-SQL-Anweisungen und RETURN eine Tabelle ausführen kann.

Interleaved Execution hilft Workload-Leistungsproblemen, die auf behobene Karte inality-Schätzungen zurückzuführen sind, die msTVFs zugeordnet 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. Während der Optimierung, wenn das Datenbankmodul auf einen Kandidaten für die interleavierte Ausführung trifft, die multianweisungsfähige Tabellenwertfunktionen (MSTVFs) verwendet, wird die Optimierung angehalten, die entsprechende Unterstruktur ausgeführt, genaue Karte inalitätsschätzungen erfasst und dann die Optimierung für downstream-Vorgänge fortgesetzt.

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.

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

• Beachten Sie, dass der MSTVF-Table Scan jetzt die genaue Kardinalitätsschätzung widerspiegelt. Beachten Sie auch die Neuanordnung dieser Tabellenüberprüfung 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 interleavierten Ausführung materialisiert, aber der Unterschied besteht darin, dass wir jetzt verzögerte Optimierung zulassen und dann die Karte inalitätsschätzung des materialisierten Zeilensatzes 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. Die Entschärfung kann rückgängig machen der Kompatibilitätsstufe oder die Verwendung von Abfragespeicher umfassen, um die nicht zurückgetretene Version des Plans zu erzwingen.

Verschachtelte Ausführung und nachfolgende Ausführungen

Nachdem ein zwischengespeicherter Ausführungsplan zwischengespeichert wurde, wird der Plan mit den überarbeiteten Schätzungen für die erste Ausführung für aufeinander folgende Ausführung verwendet, ohne die interleavierte Ausführung erneut zu überprüfen.

Nachverfolgen der interleavierten Ausführungsaktivität

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 auch interleavierte Ausführungsinstanzen über die 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 OPTION (RECOMPILE) einen neuen Plan mit interleaved Ausführung erstellt und nicht zwischenspeichert.

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 interleavierten Ausführung, ohne die Kompatibilitätsstufe zu ändern

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;

Wenn diese Einstellung aktiviert ist, wird diese Einstellung in sys.database_scoped_configurations aktiviert angezeigt. 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. 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 Konfigurations- oder Ablaufverfolgungskennzeichnungseinstellung in der Datenbank.

Inlining benutzerdefinierter Skalarfunktionen

Gilt für: SQL Server (ab SQL Server 2019 (15.x)), 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 Der Datenbankkompatibilitätsebene 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)), 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 anfänglichen Plankompilierung verteilt dieses Feature Karte inalitätsschätzungen, die auf tatsächlichen Tabellenvariablenzeilenanzahlen 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.

Um die verzögerte Kompilierung der Tabellenvariablen zu aktivieren, aktivieren Sie die Datenbankkompatibilitätsebene 150 oder höher für die Datenbank, mit der Sie verbunden sind, wenn die Abfrage ausgeführt wird.

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. Die Leistung kann durch dieses Feature möglicherweise nicht verbessert werden, wenn die Anzahl der Tabellenvariablenzeilen bei ausführungsübergreifend erheblich variiert.

Deaktivieren der verzögerten Kompilierung der Tabellenvariablen, ohne die Kompatibilitätsstufe zu ändern

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. 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 nicht uniformen Datenverteilungen der Fall.

• Weitere Informationen zur PSP-Optimierung finden Sie unter Optimierung des vertraulichen Parameters.
• Weitere Informationen zur Parameterisierung und Parameterempfindlichkeit finden Sie unter "Parameterempfindlichkeit " und "Parameter" und "Ausführungsplan wiederverwenden".

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 hierfür ist die Berechnung von COUNT(DISTINCT()) 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)), 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).

Ungefähres Quantil

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

Diese Aggregatfunktionen berechnen Quantile für ein großes Dataset mit akzeptablen rangbasierten Fehlergrenzen, um schnelle Entscheidungen mithilfe ungefährer Quantilaggregatfunktionen 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)), 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.

Übersicht über die Ausführung des Batchmodus

SQL Server 2012 (11.x) hat ein neues Feature eingeführt, um analytische Workloads zu beschleunigen: Columnstore-Indizes. Die Anwendungsfälle und die Leistung von Columnstore-Indizes wurden in jeder nachfolgenden Version von SQL Server erhöht. Das Erstellen von Spaltenspeicherindizes für 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. Viele weitere Skalierbarkeitsverbesserungen sind an die Verarbeitung im Batchmodus 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) gilt der SQL Server-Abfrageoptimierer als Batchmodusverarbeitung nur für Abfragen, die mindestens eine Tabelle mit einem Spaltenspeicherindex umfassen.

Spaltenspeicherindizes 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

Für den Batchmodus im Rowstore ist die Kompatibilitätsebene 150 der Datenbank erforderlich.

Selbst wenn eine Abfrage nicht auf Tabellen mit Spaltenspeicherindizes zugreift, verwendet der Abfrageprozessor Heuristiken, um zu entscheiden, ob der Batchmodus berücksichtigt 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_ROWSTOREDatenbankbereichskonfiguration ist standardmäßig aktiviert.

Sie können den Batchmodus im Rowstore deaktivieren, ohne die Datenbankkompatibilitätsebene 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 im Rowstore über die Konfiguration mit Datenbankbereich deaktivieren. Sie können die Einstellung jedoch weiterhin auf Abfrageebene überschreiben, indem Sie den ALLOW_BATCH_MODE Abfragehinweis 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 auch im Rowstore für eine bestimmte Abfrage mithilfe des DISALLOW_BATCH_MODE Abfragehinweiss 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 Abfrageverarbeitungsfeedbackfeatures sind Teil der intelligenten Abfrageverarbeitungsfamilie von Features.

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 nicht Karte, und die Abfrage wird ohne dieses Feedback weiterhin ausgeführt.

Informationen dazu, welche Abfrageverarbeitungsfeedbackfeatures in verschiedenen Versionen von SQL Server oder in Azure SQL-Datenbank oder Azure SQL verwaltete Instanz verfügbar sind, finden Sie in sql-Datenbanken oder den folgenden Artikeln zu den einzelnen Feedbackfeatures.

Feedback zur Speicherzuweisung

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

Feedback zur Speicherzuweisung im Batchmodus

Informationen zum Feedback zur Speichererteilung im Batchmodus finden Sie unter "Batchmodus Speicherzuteilungsfeedback".

Feedback zur Speicherzuweisung im Zeilenmodus

Informationen zum Feedback zur Speichererteilung im Zeilenmodus finden Sie unter "Feedback zur Speichererteilung im Zeilenmodus".

Feedback zur Speicherzuweisung im Perzentil- und Persistenzmodus

Informationen zu Perzentil- und Persistenzmodus-Speicherzuteilungsfeedback finden Sie unter Quantil- und Persistenzmodus-Speicherzuteilungsfeedback.For information about percentile and per persist mode memory grant feedback.

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 zu CE-Feedback finden Sie im Feedback zur Kardinalitätsschätzung (CE).

Erzwingen des optimierten Plans mit dem Abfragespeicher

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

Zugehöriger Inhalt

• Joins (SQL Server)
• Ausführungsmodi
• Leitfaden zur Architektur der Abfrageverarbeitung
• Referenz zu logischen und physischen Showplanoperatoren
• ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
• Neues in SQL Server 2017
• Neuerungen in SQL Server 2019
• Neuerungen in SQL Server 2022
• Demo zur intelligenten Abfrageverarbeitung
• Reduktion konstanter Ausdrücke und Auswertung von Ausdrücken
• Intelligente Abfrageverarbeitungsdemos auf GitHub
• Leistungscenter für SQL Server-Datenbank-Engine und Azure SQL-Datenbank
• Überwachen der Leistung mithilfe des Abfragespeichers
• Bewährte Methoden für die Überwachung von Workloads mit Abfragespeicher