Features der intelligenten Abfrageverarbeitung im Detail

Gilt für:SQL ServerAzure SQL-DatenbankVerwaltete Azure SQL-InstanzSQL-Datenbank in Microsoft Fabric

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;

Weitere Informationen zu den Änderungen, die mit neuen Versionen eingeführt wurden, finden Sie unter:

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

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 „Adaptive Join“ definiert einen Schwellenwert, anhand dessen entschieden wird, wann zu einem Nested-Loops-Plan gewechselt wird. Daher kann Ihr Plan während der Ausführung dynamisch auf eine bessere Join-Strategie umschalten.

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 interleaved Ausführung werden die tatsächlichen Zeilenanzahlen der Funktion verwendet, um fundiertere Entscheidungen für den nachgelagerten Abfrageplan zu treffen.

MSTVFs haben ab SQL Server 2014 (12.x) eine feste Kardinalitätsschätzung von 100 und für frühere SQL Server-Versionen von 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, falls das Datenbankmodul einen Kandidaten für die interleavierte Ausführung findet, die multianweisungsfähige Tabellenwertfunktionen (MSTVFs) verwendet, pausiert die Optimierung, führt die anwendbare Unterstruktur aus, erfasst genaue Kardinalitätsschätzungen und setzt dann die Optimierung für Downstream-Vorgänge fort.

Die folgende Abbildung zeigt die Ausgabe von Live Query Statistics, einer Teilmenge eines gesamten Ausführungsplans, die die Auswirkungen fester Kardinalitätsschätzungen aus MSTVFs zeigt.

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-Tabellenscan hat eine feste Schätzung von 100 Zeilen. In diesem Beispiel fließen jedoch 527.597 Zeilen durch diesen MSTVF Table Scan, wie in den Live-Abfragestatistiken anhand von 527597 von 100 tatsächlich statt geschätzt zu sehen ist – die feste Schätzung ist also erheblich verzerrt.
• Für die Nested-Loops-Operation wird davon ausgegangen, dass von der äußeren Seite des Joins nur 100 Zeilen zurückgegeben werden. Angesichts der hohen Anzahl von Zeilen, die tatsächlich von der MSTVF zurückgegeben werden, ist es wahrscheinlich besser, einen anderen Verknüpfungsalgorithmus zu verwenden.
• 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 erzeugten Plan bei aktivierter verschränkter Ausführung:

• Der MSTVF-Tabellenscan spiegelt nun eine genaue Kardinalitätsschätzung wider. Beachten Sie auch die Umordnung dieses Tabellenscans und der anderen Operationen.
• Und was die Joinalgorithmen betrifft, haben wir statt einer Nested-Loop-Operation zu einer Hash-Match-Operation gewechselt, was angesichts der großen Anzahl von 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.

Für alternierende Ausführung zulässige Anweisungen

Verweisanweisungen von MSTVF in verschachtelten Ausführungen müssen aktuell schreibgeschützt sein und dürfen nicht Teil eines Datenmodifizierungsvorgangs sein. Außerdem sind MSTVFs nicht für die verschachtelte Ausführung geeignet, wenn sie keine 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:

• Es gibt eine große Abweichung zwischen der geschätzten und tatsächlichen Anzahl von Zeilen für die Zwischenergebnismenge (in diesem Fall die MSTVF).

• Und die gesamte Abfrage reagiert empfindlich auf eine Änderung der Größe des Zwischenergebnisses. Dies tritt normalerweise auf, wenn im Abfrageplan über dieser Unterstruktur ein komplexer Baum vorliegt.

  Eine Grundlegende SELECT * aus einem MSTVF profitiert nicht von der interleavierten 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. Wie bei allen Änderungen, die einen Ausführungsplan beeinflussen, können sich einige Pläne so ändern, dass wir trotz einer besseren Kardinalitätsschätzung für den Teilbaum insgesamt einen schlechteren Plan für die Abfrage erhalten. Zu den Abhilfemaßnahmen kann gehören, den Kompatibilitätsgrad zurückzusetzen oder Abfragespeicher zu verwenden, um die nicht regressierte Version des Ausführungsplans zu erzwingen.

Verschränkte Ausführung und aufeinanderfolgende 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.

Nachverfolgen ineinander verschränkter Ausführungsaktivität

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

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

Eine Abfrage muss ausgeführt werden, damit Interleaved Execution die MSTVF-Kardinalitätsschätzungen ü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.

Zwischenspeicherung verzahnter Ausführung

Wenn ein Plan aus dem Cache gelöscht oder aus dem Cache entfernt wird, gibt es bei der Abfrageausführung eine neue Kompilierung, die interleavierte Ausführung verwendet. Eine Anweisung, die OPTION (RECOMPILE) verwendet, erstellt einen neuen Plan mit interleaver Ausführung und speichert diesen nicht im Cache.

Verschachtelte Ausführung und Abfragespeicher-Interoperabilität

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

Interleaved-Ausführung deaktivieren, ohne den Kompatibilitätsgrad zu ändern

Die interleaved Ausführung kann auf Datenbank- oder Anweisungsebene deaktiviert werden, wobei der Datenbankkompatibilitätsgrad 140 oder höher beibehalten wird. 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 die interleaved Ausführung für eine bestimmte Abfrage auch deaktivieren, indem Sie DISABLE_INTERLEAVED_EXECUTION_TVF als USE HINT-Abfragehinweis angeben. Beispiel:

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

Ein USE HINT-Abfragehinweis hat Vorrang vor einer datenbankbezogenen Konfiguration oder einer Trace-Flag-Einstellung.

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 Ausführungspläne anstelle ineffizienter, iterativer, serieller Ausführungspläne. Dieses Feature ist standardmäßig unter dem Datenbank-Kompatibilitätsgrad 150 oder höher aktiviert.

Weitere Informationen finden Sie unter Inlining von Scalar UDFs.

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 genauen Zeilenanzahlinformationen werden dann zum Optimieren von Downstreamplanvorgängen 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.

Eine Tabellenvariablenzeilenanzahl, die für die anfängliche Plankompilierung verwendet wird, stellt einen typischen Wert dar, der sich von einer festen Anzahl von Zeilen unterscheiden kann. Wenn dies anders ist, profitieren downstream-Vorgä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. 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 2022 (16.x) und höhere Versionen von Azure SQL-DatenbankAzure SQL Managed Instance

Die PSP-Optimierung (Parameter Sensitivity Plan) ist Teil der Featurefamilie der intelligenten Abfrageverarbeitung. Dieser wurde für Szenarios 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.

• Weitere Informationen zur PSP-Optimierung finden Sie unter Optimierung des Parameterempfindlichkeitsplans.
• Weitere Informationen über Parametrisierung und Parametersensitivität finden Sie unter Parametersensitivität und Parameter und Wiederverwendung von Ausführungsplänen.

Geschätzte Abfrageverarbeitung

Approximative Abfrageverarbeitung ist eine neue Featuregruppe. 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.

Ungefähre Anzahl unterschiedlicher Werte

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.

Ungefähres Quantil

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

Diese Aggregatfunktionen berechnen mithilfe approximativer Perzentil-Aggregatfunktionen Perzentile für einen großen Datensatz mit akzeptablen rangbasierten Fehlergrenzen und ermöglichen so schnelle Entscheidungen.

Weitere Informationen finden Sie unter APPROX_PERCENTILE_DISC und APPROX_PERCENTILE_CONT

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.

Vorhandene Abfragen, die am meisten vom Batchmodus im Rowstore profitieren können, umfassen:

• Hash-Verknüpfungen zwischen großen Zeilenspeichertabellen
• Abfragen mit GROUP BY über viele unterschiedliche Werte
• Aggregatfunktionen wie SUM, COUNT, MIN, MAXAVG
• Fensterfunktionsabfragen mit OVER, PARTITION BYund ORDER BY, einschließlich Aggregatfunktionen und ROW_NUMBERRANK

Weitere Informationen zur Leistung von Fensterfunktionen finden Sie in den Überlegungen zur Leistung in der OVER Klauselreferenz.

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. Sie arbeiten mit einem Stapel von Zeilen, anstatt jeweils eine einzelne Zeile zu verarbeiten. 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. Zum Beispiel können Aggregate im Batchmodus als Teil eines Columnstoreindexscans ausgewertet werden. Außerdem werden komprimierte Columnstore-Daten, die mithilfe der Lauflängencodierung komprimiert sind, mit Joins im Batchmodus und Aggregaten im Batchmodus wesentlich effizienter verarbeitet.

Es ist jedoch wichtig zu verstehen, dass die beiden Features unabhängig 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. Beispielsweise sind direkte Änderungen nicht mit der Spaltenspeicherkomprimierung kompatibel. Daher werden Auslöser in Tabellen mit gruppierten Columnstore-Indizes nicht unterstützt. Noch wichtiger ist, dass Columnstore-Indizes zusätzlichen Aufwand für DELETE- und UPDATE-Anweisungen verursachen.

Bei einigen hybriden transaktionalen/analytischen Workloads überwiegt der Mehraufwand eines transaktionalen Workloads die Vorteile von Columnstore-Indizes. 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 bei der Eingabe/Ausgabe liegt, empfiehlt es sich weiterhin, wenn möglich einen Columnstore-Index zu berücksichtigen.
• Das Erstellen eines Columnstore-Index fügt dem transaktionalen Teil Ihrer Workload zu viel Mehraufwand hinzu. Oder das Erstellen eines Columnstore-Indexes ist nicht machbar, da Ihre Anwendung von einem Feature abhängt, das noch nicht mit Spaltenspeicherindizes unterstützt wird.

Welche Änderungen mit dem Batchmodus auf Rowstore verbunden sind

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

Auch 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 Batchmodus für Rowstore verwendet wird, wird der tatsächliche Ausführungsmodus im Abfrageplan als Batchmodus angezeigt. Der Scan-Operator verwendet den Batchmodus für On-Disk-Heaps und B-Struktur-Indizes. Dieser Scan im Batchmodus kann Bitmapfilter im Batchmodus bewerten. Vielleicht finden Sie auch andere Batchmodusoperatoren im Plan. Beispiele sind Hashjoins, hashbasierte Aggregate, Sortierungen, Fensteraggregate, Filter, Verkettung und Skalarberechnungsoperatoren.

Remarks

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 Ausführungsplan im Zeilenmodus erhalten, ist dieser möglicherweise nicht derselbe wie der Ausführungsplan, den Sie bei einer niedrigeren Kompatibilitätsstufe erhalten. Und wenn Sie einen Plan im Batchmodus erhalten, ist er möglicherweise nicht derselbe wie der Plan, den Sie mit einem Columnstore-Index erhalten.

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

Aktuell bestehen folgende Einschränkungen für den neuen Batchmodus beim Rowstore-Scan:

• Es greift weder für In-Memory-OLTP-Tabellen noch für andere Indizes als datenträgerbasierte Heaps und B-Bäume.
• Es greift auch nicht, wenn eine Large-Object-(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'));

Feedbackfunktionen 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. Wenn dies erfolgreich ist, speichern wir diese Änderungen zur späteren Verwendung auf dem Datenträger, im Arbeitsspeicher und/oder im Abfragespeicher. 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-Datenbank 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.

Rückmeldung zur Speichergewährung

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

Rückmeldung zum Parallelitätsgrad (DOP)

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

Erzwingen optimierter Pläne mit Abfragespeicher

Informationen zur optimierten Planerzwingung mit dem Abfragespeicher finden Sie unter Optimierte Planerzwingung mit dem Abfragespeicher.

Verwandte Inhalte

• Joins (SQL Server)
• Ausführungsmodi
• Leitfaden zur Architektur der Abfrageverarbeitung
• Referenz zu logischen und physischen Showplan-Operatoren
• 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
• Konstantenfaltung und Ausdrucksauswertung
• Demos zur intelligenten Abfrageverarbeitung 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