Columnstore-Indizes: Abfrageleistung

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Empfehlungen zum Erreichen der sehr schnellen Abfrageleistung, die Columnstore-Indizes vom Design her bereitstellen können sollten.

Columnstore-Indizes können eine bis zu 100-fach bessere Leistung für Analyse- und Data Warehousing-Arbeitsauslastungen und eine bis zu 10-fach bessere Datenkomprimierung als herkömmliche Rowstore-Indizes erreichen. Diese Empfehlungen unterstützen Sie beim Erzielen der schnellen Abfrageleistung, für die Columnstore-Indizes entwickelt wurden. Weitere Erläuterungen zur Columnstore-Leistung finden Sie am Ende.

Empfehlungen zur Verbesserung der Abfrageleistung

Im Folgenden finden Sie einige Empfehlungen zum Erreichen der hohen Leistung, für die Columnstore-Indizes entwickelt wurden.

1. Organisieren Sie Daten, um weitere Zeilengruppen im Rahmen eines vollständigen Tabellenscans zu beseitigen.

  • Nutzen Sie die Einfügereihenfolge. Im Allgemeinen werden in einem herkömmlichen Data Warehouse die Daten in zeitlicher Reihenfolge eingefügt. Die Analyse erfolgt in der Zeitdimension. Beispiel: Analyse der Umsätze nach Quartal. Für diese Art der Arbeitsauslastung wird das Löschen der Zeilengruppe automatisch durchgeführt. In SQL Server 2016 (13.x) können Sie herausfinden, welche Zeilengruppen als Teil der Abfrageverarbeitung übersprungen wurden.

  • Nutzen Sie den gruppierten Rowstore-Index. Wenn das allgemeine Abfrageprädikat für eine Spalte (z. B. C1) gilt, die nicht mit der Einfügereihenfolge der Zeile verbunden ist, können Sie einen gruppierten Rowstore-Index für die Spalte C1 erstellen und durch das Löschen des gruppierten Rowstore-Indexes einen gruppierten Columnstore-Index erstellen. Wenn Sie bei der Erstellung des gruppierten Columnstore-Indexes explizit MAXDOP = 1 verwenden, wird der resultierende gruppierte Columnstore-Index nach Spalte C1 sortiert. Bei Angabe von MAXDOP = 8 können Sie eine Überlappung der Werte über acht Zeilengruppen beobachten. Ein häufiges Szenario für diese Strategie, wenn Sie zu Beginn einen Columnstore-Index mit großer Datenmenge erstellen. Beachten Sie bei einem nicht gruppierten Columnstore-Index (NCCI), dass die grundlegende Rowstore-Tabelle über einen gruppierten Index verfügt. Die Zeilen sind bereits sortiert. In diesem Fall wird der resultierende Columnstore-Index automatisch sortiert. Beachten Sie unbedingt Folgendes: Der Columnstore-Index behält die Reihenfolge der Zeilen nicht inhärent bei. Wenn neue Zeilen eingefügt oder ältere Zeilen aktualisiert werden, müssen Sie den Vorgang ggf. wiederholen, da die Abfrageleistung der Analyse abnehmen kann.

  • Nutzen Sie die Tabellenpartitionierung. Sie können den Columnstore-Index partitionieren und dann durch Entfernen der Partition die Anzahl der zu scannenden Zeilengruppen reduzieren. Beispielsweise speichert eine Faktentabelle Einkäufe von Kunden. Ein gängiges Abfragemuster besteht darin, vierteljährliche Einkäufe von einem bestimmten Kunden zu finden, sie können die Einfügereihenfolge mit Partitionierung in der Kundenspalte kombinieren. Jede Partition enthält zeitlich sortierte Zeilen für einen bestimmten Kunden. Sie sollten auch die Verwendung von Tabellenpartitionierung in Betracht ziehen, wenn Daten aus dem Columnstore entfernt werden müssen. Das Auslagern und Abschneiden von Partitionen, die nicht mehr benötigt werden, ist eine effiziente Strategie zum Löschen von Daten, ohne Fragmentierung zu generieren, die durch kleinere Zeilengruppen eingeführt wird.

  • Vermeiden Sie das Löschen großer Datenmengen. Das Entfernen von komprimierten Zeilen aus einer Zeilengruppe ist kein synchroner Vorgang. Es wäre teuer, eine Zeilengruppe zu dekomprimieren, die Zeile zu löschen und dann erneut zu komprimieren. Wenn Sie also Daten aus komprimierten Zeilengruppen löschen, werden diese Zeilengruppen weiterhin überprüft, auch wenn sie weniger Zeilen zurückgeben. Wenn die Anzahl der gelöschten Zeilen für mehrere Zeilengruppen groß genug ist, damit diese in weniger Zeilengruppen zusammengeführt werden können, erhöht die Neuorganisation des Columnstore die Qualität des Indexes, und die Abfrageleistung wird verbessert. Wenn bei der Datenlöschung normalerweise ganze Zeilengruppen entfallen, sollten Sie die Verwendung von Tabellenpartitionierung, das Auslagern von Partitionen, die nicht mehr benötigt werden, und das Abschneiden von Zeilen anstelle einer Löschung in Betracht ziehen.

    Hinweis

    Ab SQL Server 2019 (15.x) wird der Tupel-Mover von einer Hintergrundzusammenführungsaufgabe unterstützt, die automatisch kleinere OPEN-Delta-Zeilengruppen komprimiert, die seit einiger Zeit vorhanden sind, wie durch einen internen Schwellenwert festgelegt, oder komprimiert komprimierte Zeilengruppen, aus denen eine große Anzahl von Zeilen gelöscht wurde. Dies verbessert die Qualität des Columnstore-Index im Lauf der Zeit.
    Wenn das Löschen von großen Datenmengen aus dem Columnstore-Index erforderlich ist, empfiehlt es sich, diesen Vorgang nach und nach in kleinere Löschbatches aufzuteilen. Dies ermöglicht es dem Mergetask im Hintergrund, kleinere Zeilengruppen zu mergen und die Indexqualität zu verbessern, sodass nach dem Löschen von Daten keine Wartungsfenster für Indexumstrukturierung vorgesehen werden müssen.
    Weitere Informationen zu Spaltenspeicherbegriffen und -konzepten finden Sie unter Columnstore-Indizes: Übersicht.

2. Planen Sie ausreichend Arbeitsspeicher für eine parallele Erstellung von Columnstore-Indizes ein

Bei der Erstellung eines Columnstore-Indexes handelt es sich standardmäßig um einen parallel ausgeführten Vorgang, sofern der verfügbare Arbeitsspeicher nicht eingeschränkt ist. Die parallele Indexerstellung erfordert mehr Arbeitsspeicher als die serielle Erstellung des Index. Wenn ausreichend Arbeitsspeicher verfügbar ist, dauert das Erstellen eines Columnstore-Indexes 1,5-mal so lange wie das Erstellen einer B-Struktur für die gleichen Spalten.

Der Speicherplatz, der für das Erstellen eines Columnstore-Indexes erforderlich ist, hängt von der Anzahl von Spalten, der Anzahl der Zeichenfolgenspalten, dem Grad der Parallelität (Degree of Parallelism, DOP) und von den Eigenschaften der Daten ab. Wenn ihre Tabelle beispielsweise weniger als 1 Millionen Zeilen enthält, verwendet SQL Server nur einen Thread, um den Spaltenspeicherindex zu erstellen.

Wenn Ihre Tabelle über mehr als 1 Millionen Zeilen verfügt, SQL Server jedoch keine große Speicherzuteilung erhalten kann, um den Index mit MAXDOP zu erstellen, wird SQL Server bei Bedarf automatisch verringert MAXDOP , um in die verfügbare Speichererteilung einzupassen. In bestimmten Fällen muss DOP auf eins verringert werden, um den Index mit eingeschränktem Arbeitsspeicher zu erstellen.

Ab SQL Server 2016 (13.x) wird die Abfrage immer im Batchmodus ausgeführt. In früheren Versionen wird die Batchausführung nur verwendet, wenn DOP größer als 1 ist.

Erläuterungen zur Columnstore-Leistung

Columnstore-Indizes erzielen eine hohe Abfrageleistung durch die Kombination der Hochgeschwindigkeits-In-Memory-Modusbatchverarbeitung mit Techniken, die E/A-Anforderungen erheblich reduzieren. Da bei analytischen Abfragen eine große Anzahl von Zeilen gescannt werden, sind diese in der Regel E/A-gebunden, sodass eine E/A-Reduzierung während der Abfrageausführung maßgeblich für das Design der Columnstore-Indizes ist. Sobald die Daten in den Arbeitsspeicher gelesen wurden, ist es wichtig, dass die Anzahl der In-Memory-Vorgänge reduziert wird.

Columnstore-Indizes reduzieren die E/A-Vorgänge und optimieren die In-Memory-Vorgänge mithilfe einer hohen Datenkomprimierung sowie der Columnstore-Löschung, der Löschung von Zeilengruppen und der Batchverarbeitung.

Datenkomprimierung

Columnstore-Indizes erzielen eine bis zu 10 Mal höhere Datenkomprimierung als Rowstore-Indizes. Dadurch werden die zum Ausführen der Analyseabfragen erforderlichen E/A-Vorgänge erheblich verringert, wodurch die Abfrageleistung verbessert wird.

  • Columnstore-Indizes lesen komprimierte Daten vom Datenträger, was bedeutet, dass weniger Datenbytes in den Arbeitsspeicher gelesen werden müssen.

  • Columnstore-Indizes speichern Daten in komprimierter Form im Arbeitsspeicher, wodurch E/A-Vorgänge reduziert werden, da die Häufigkeit der Lesevorgänge der gleichen Daten in den Arbeitsspeicher verringert wird. Beispielsweise können Columnstore-Indizes bei zehnfacher Komprimierung zehnmal mehr Daten im Arbeitsspeicher aufbewahren als bei der Speicherung der Daten in unkomprimierter Form. Wenn sich mehr Daten im Arbeitsspeicher befinden, ist es wahrscheinlicher, dass der Columnstore-Index die benötigten Daten im Arbeitsspeicher findet, ohne dass zusätzliche Lesevorgänge vom Datenträger anfallen.

  • Columnstore-Indizes komprimieren Daten nach Spalten anstatt nach Zeilen, wodurch hohe Komprimierungsraten erzielt und die Größe der auf dem Datenträger gespeicherten Daten reduziert werden. Jede Spalte wird separat komprimiert und gespeichert. Daten in einer Spalte haben immer den gleichen Datentyp und tendenziell auch ähnliche Werte. Die Datenkomprimierungstechniken sind sehr gut, um höhere Komprimierungsraten zu erreichen, wenn die Werte ähnlich sind.

  • Wenn beispielsweise eine Faktentabelle Kundenadressen speichert und eine Spalte für Land/Region enthält, beträgt die Gesamtanzahl möglicher Werte weniger als 200. Einige dieser Werte werden mehrmals wiederholt. Wenn die Faktentabelle 100 Millionen Zeilen enthält, wird die Spalte "Land/Region" einfach komprimiert und erfordert nur sehr wenig Speicherplatz. Die Zeilen-nach-Zeilen-Komprimierung ist nicht in der Lage, die Ähnlichkeit von Spaltenwerten auf diese Weise groß zu machen und verwendet mehr Bytes, um die Werte in der Spalte "Land/Region" zu komprimieren.

Spaltenlöschung

Columnstore-Indizes überspringen den Lesevorgang von Spalten, die für das Ergebnis der Abfrage nicht erforderlich sind. Durch die sogenannte Spaltenlöschung werden die E/A-Vorgänge für die Abfrageausführung weiter reduziert, wodurch die Abfrageleistung verbessert wird.

  • Die Spaltenlöschung ist möglich, da die Daten nach Spalten organisiert und komprimiert sind. Im Gegensatz dazu werden beim zeilenweisen Speichern von Daten die Werte der einzelnen Zeilen physisch zusammen gespeichert und können nicht problemlos getrennt werden. Der Abfrageprozessor muss eine ganze Zeile einlesen, um bestimmte Spaltenwerte abrufen zu können, wodurch die Zahl der E/A-Vorgänge erhöht wird, da zusätzliche Daten unnötigerweise in den Arbeitsspeicher gelesen werden.

  • Wenn eine Tabelle beispielsweise 50 Spalten hat und die Abfrage nur 5 dieser Spalten verwendet, ruft der Columnstore-Index nur die 5 Spalten vom Datenträger ab. Das Einlesen der anderen 45 Spalten wird übersprungen. Dadurch werden die E/A-Vorgänge um weitere 90 % reduziert, vorausgesetzt, dass alle Spalten eine ähnliche Größe aufweisen. Wenn die gleichen Daten in einer Zeilengruppe gespeichert sind, muss der Abfrageprozessor die zusätzlichen 45 Spalten lesen.

Zeilengruppenlöschung

Bei vollständigen Tabellenscans entspricht ein großer Prozentsatz der Daten in der Regel nicht den Abfrageprädikatskriterien. Mithilfe von Metadaten kann der Columnstore-Index das Einlesen der Zeilengruppen überspringen, die keine für das Abfrageergebnis erforderlichen Daten enthalten. Dabei werden keine tatsächlichen E/A-Vorgänge durchgeführt. Durch die sogenannte Zeilengruppenlöschung werden die E/A-Vorgänge für vollständige Tabellenscans weiter reduziert, wodurch die Abfrageleistung verbessert wird.

Wann muss ein Columnstore-Index einen vollständigen Tabellenscan durchführen?

Ab SQL Server 2016 (13.x) können Sie einen oder mehrere reguläre, nicht gruppierte B-Strukturindizes in einem gruppierten Columnstore-Index erstellen, genau wie bei einem Rowstore-Heap. Die nicht gruppierten B-Strukturindizes können eine Abfrage mit einem Gleichheitsprädikat oder einem Prädikat mit einem kleinen Wertebereich beschleunigen. Bei komplexeren Prädikaten kann der Abfrageoptimierer sich für einen vollständigen Tabellenscan entscheiden. Ohne die Fähigkeit, Zeilengruppen zu überspringen, wäre ein vollständiger Tabellenscan sehr zeitaufwändig, insbesondere bei großen Tabellen.

Wann profitiert eine Analyseabfrage von einer Zeilengruppenlöschung für einen vollständigen Tabellenscan?

Ein Einzelhandelsunternehmen hat beispielsweise seine Vertriebsdaten mithilfe einer Faktentabelle mit gruppiertem Columnstore-Index modelliert. Bei jedem neuen Verkauf werden verschiedene Attribute der Transaktion gespeichert, einschließlich des Verkaufsdatums eines Produkts. Obwohl Columnstore-Indizes keine sortierte Reihenfolge sicherstellen, werden die Zeilen in dieser Tabelle interessanterweise nach Datum sortiert geladen. Mit der Zeit wächst diese Tabelle. Auch wenn das Einzelhandelsunternehmen Verkaufsdaten der letzten 10 Jahre speichert, muss bei einer Analyseabfrage nur ein Aggregat für das letzte Quartal berechnet werden. Mit Columnstore-Indizes können Sie es vermeiden, auf die Daten der vorherigen 39 Quartale zuzugreifen, indem nur die Metadaten für die Datumsspalte untersucht werden. Dies entspricht einer zusätzlichen Reduzierung der Datenmenge, die in den Arbeitsspeicher gelesen und verarbeitet wird, von 97 %.

Welche Zeilengruppen werden bei einem vollständigen Tabellenscan übersprungen?

Um zu bestimmen, welche Zeilengruppen gelöscht werden sollen, verwendet der Columnstore-Index Metadaten, um die Mindest- und Maximalwerte jedes Spaltensegments für jede Zeilengruppe zu speichern. Wenn keiner der Spaltensegmentbereiche die Kriterien für Abfrageprädikate erfüllt, wird die gesamte Zeilengruppe übersprungen, ohne tatsächliche E/A-Vorgänge auszuführen. Dies funktioniert, da die Daten in der Regel in sortierter Reihenfolge geladen werden, und auch wenn eine Sortierung der Zeilen nicht garantiert werden kann, befinden sich ähnliche Datenwerte häufig innerhalb derselben Zeilengruppe oder in einer benachbarten Zeilengruppe.

Weitere Informationen zu Zeilengruppen finden Sie in den Richtlinien für den Spaltenspeicherindexentwurf.

Batchmodusausführung

Bei der Batchmodusausführung handelt es sich um die gemeinsame Verarbeitung eines Rowsets, in der Regel bis zu 900 Zeilen, aus Gründen der Ausführungseffizienz. Die Abfrage SELECT SUM (Sales) FROM SalesData aggregiert beispielsweise den Gesamtumsatz aus der Tabelle „SalesData“. Bei der Batchmodusausführung berechnet die Abfrageausführungs-Engine das Aggregat in Gruppen von 900 Werten. Dadurch werden Metadaten, Zugriffskosten und andere Aufwandsarten auf alle Zeilen in einem Batch verteilt, anstatt die Kosten für jede Zeile zu zahlen, wodurch der Codepfad erheblich reduziert wird. Bei der Batchmodusverarbeitung kommen, sofern möglich, komprimierte Daten zum Einsatz. Zugleich werden einige der Exchange-Operatoren beseitigt, die bei der Zeilenmodusverarbeitung verwendet werden. Dies beschleunigt die Ausführung von Analyseabfragen in beträchtlichem Maße.

Nicht alle Abfrageausführungsoperatoren können im Batchmodus ausgeführt werden. DML-Vorgänge, wie z. B. Einfügen, Löschen oder Aktualisieren, werden z. B. Zeile für Zeile ausgeführt. Batchmodusoperatoren richten sich an Operatoren, um die Abfrageleistung wie Scan, Join, Aggregate, Sort und so weiter zu beschleunigen. Da der Columnstore-Index in SQL Server 2012 (11.x) eingeführt wurde, besteht ein anhaltender Aufwand, um die Operatoren zu erweitern, die im Batchmodus ausgeführt werden können. Die folgende Tabelle führt die Operatoren auf, die im Batchmodus gemäß der Produktversion ausgeführt werden.

Batchmodusoperatoren Einsatz SQL Server 2012 (11.x) SQL Server 2014 (12.x) SQL Server 2016 (13.x) und SQL-Datenbank1 Bemerkungen
DML-Vorgänge (Insert, Delete, Update, Merge) Nein Nein Nein DML ist kein Batchmodusvorgang, da es nicht parallel ist. Auch wenn die serielle Batchmodusverarbeitung aktiviert wird, kommt es zu keiner maßgeblichen Leistungssteigerung, wenn DML im Batchmodus verarbeitet wird.
Columnstore Index Scan SCAN Nicht verfügbar ja ja Bei Columnstore-Indizes kann das Prädikat mittels Push an den SCAN-Knoten übertragen werden.
Columnstore-Indexscan (nicht gruppiert) SCAN ja Ja Ja ja
Index Seek Nicht verfügbar Nicht verfügbar Nein Wir führen einen Suchvorgang über einen nicht gruppierten B-Strukturindex im Zeilenmodus aus.
Compute Scalar Ausdruck, dessen Auswertung einen Skalarwert ergibt. ja Ja ja Es gibt jedoch einige Einschränkungen hinsichtlich des Datentyps. Dies gilt für alle Batchmodusoperatoren.
Verkettung UNION und UNION ALL Nein ja ja
filter Anwenden von Prädikaten ja Ja ja
Hash Match Hashbasierte Aggregatfunktionen, äußerer Hashjoin, rechter Hashjoin, linker Hashjoin, rechter innerer Join, linker innerer Join ja Ja ja Einschränkungen für die Aggregation: keine Mindest-/Maximalwerte für Zeichenfolgen. Verfügbare Aggregationsfunktionen: sum/count/avg/min/max.
Einschränkungen für Join: keine nicht übereinstimmenden Typ-Joins für nicht ganzzahlige Typen.
Merge Join Nein Nein Nein
Multithread-Abfragen ja Ja ja
Nested Loops Nein Nein Nein
Singlethread-Abfragen unter MAXDOP 1 Nein nein ja
Singlethread-Abfragen mit einem seriellen Abfrageplan Nein nein ja
Sortieren Order by-Klausel für SCAN mit Columnstore-Index Nein nein ja
Top Sort Nein nein ja
Window Aggregates Nicht verfügbar Nicht verfügbar ja Neuer Operator in SQL Server 2016 (13.x).

1 Gilt für SQL Server 2016 (13.x), SQL Database Premium-Ebenen, Standardebenen – S3 und höher sowie alle vCore-Ebenen und das Analytics Platform System (PDW)

Weitere Informationen finden Sie im Handbuch zur Architektur der Abfrageverarbeitung.

Aggregierter Pushdown

Ein normaler Ausführungspfad zur Aggregatberechnung, um die qualifizierenden Zeilen aus dem SCAN-Knoten abzurufen und die Werte im Batchmodus zu aggregieren. Dies bietet zwar eine gute Leistung, aber mit SQL Server 2016 (13.x) kann der Aggregatvorgang an den SCAN-Knoten übertragen werden, um die Leistung der Aggregatberechnung durch Größenordnungen über der Batchmodusausführung zu verbessern, vorausgesetzt, die folgenden Bedingungen sind erfüllt:

  • Bei den Aggregaten handelt es sich um MIN, MAX, SUM, COUNT und COUNT(*).
  • Der Aggregatoperator muss sich über dem SCAN-Knoten oder über dem SCAN-Knoten mit GROUP BY befinden.
  • Dieses Aggregat ist kein eindeutiges Aggregat.
  • Die Aggregatspalte ist keine Zeichenfolgenspalte.
  • Die Aggregatspalte ist keine virtuelle Spalte.
  • Der Eingabe- und Ausgabedatentyp muss einer der folgenden Sein und muss innerhalb von 64 Bits passen:
    • tinyint, int, bigint, smallint, bit
    • smallmoney, moneyund decimalnumeric mit Genauigkeit <= 18
    • smalldate, date, datetime, datetime2, time

Die Aggregatweitergabe wird beispielsweise in den beiden folgenden Abfragen durchgeführt:

SELECT  productkey, SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI
GROUP BY productkey;
    
SELECT  SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI;

Zeichenfolgenprädikatweitergabe

Beim Entwurf eines Data Warehouse-Schemas besteht die empfohlene Schemamodellierung darin, ein Sternschema oder Schneeflockenschema zu verwenden, das aus einer oder mehreren Faktentabellen und vielen Dimensionstabellen besteht. Die Faktentabelle speichert die Unternehmensmessungen oder -transaktionen, und die Dimensionstabelle speichert die Dimensionen, anhand derer die Fakten analysiert werden müssen.

Bei einem Fakt kann es sich beispielsweise um einen Datensatz für den Verkauf eines bestimmten Produkts in einer bestimmten Region handeln, während die Dimension eine Reihe von Regionen, Produkten usw. darstellt. Die Fakten- und Dimensionstabellen sind über eine Primär-/Fremdschlüsselbeziehung miteinander verbunden. Die am häufigsten verwendeten Abfragen verbinden eine oder mehrere Dimensionstabellen mit der Faktentabelle.

Betrachten Sie z.B. eine Dimensionstabelle namens Products. Ein typischer Primärschlüssel wäre ProductCode, der in der Regel als Zeichenfolgendatentyp dargestellt wird. Für die Abfrageleistung hat es sich bewährt, einen Ersatzschlüssel zu erstellen (in der Regel eine Spalte mit ganzen Zahlen), um aus der Faktentabelle auf die Zeile in der Dimensionstabelle zu verweisen.

Der Columnstore-Index führt die Analyseabfragen mit Joins/Prädikaten mit Schlüsseln auf numerischer Basis bzw. Ganzzahlbasis sehr effizient aus. Bei vielen Kundenworkloads wurden jedoch zeichenfolgenbasierte Spalten verwendet, die Fakt-/Dimensionstabellen verknüpfen. Dies führte dazu, dass die Abfrageleistung mit Columnstore-Indizes nicht gut war. SQL Server 2016 (13.x) verbessert die Leistung von Analyseabfragen mit zeichenfolgenbasierten Spalten erheblich, indem die Prädikate mit Zeichenfolgenspalten an den SCAN-Knoten übertragen werden.

Die Weitergabe von Zeichenfolgenprädikaten nutzt zur Verbesserung der Abfrageleistung das primäre bzw. sekundäre Wörterbuch, das für die Spalten erstellt wurde. Nehmen Sie z. B. ein Zeichenfolgenspaltensegment in einer Zeilengruppe, bestehend aus 100 unterschiedlichen Zeichenfolgenwerten. Das bedeutet, dass bei einer Million Zeilen auf jeden einzelnen Zeichenfolgenwert durchschnittlich 10.000 Mal verwiesen wird.

Bei der Zeichenfolgenprädikatweitergabe berechnet die Abfrageausführung das Prädikat anhand der Werte im Wörterbuch. Wenn sich dies qualifiziert, werden alle Zeilen mit Bezug auf den Wörterbuchwert automatisch qualifiziert. Dies verbessert die Leistung auf zwei Arten:

  1. Es wird nur die qualifizierte Zeile zurückgegeben, wodurch die Anzahl der Zeilen reduziert wird, die aus dem SCAN-Knoten übertragen werden müssen.

  2. Die Anzahl von Zeichenfolgenvergleichen wird maßgeblich verringert. In diesem Beispiel sind nur 100 Zeichenfolgenvergleiche gegenüber einer Millionen Vergleiche erforderlich. Wie im Folgenden beschrieben gibt es einige Einschränkungen:

    • Keine Zeichenfolgenprädikatweitergabe für Deltazeilengruppen. Es gibt kein Wörterbuch für Spalten in Deltazeilengruppen.
    • Kein Zeichenfolgen-Prädikat-Pushdown, wenn das Wörterbuch 64-KB-Einträge überschreitet.
    • Ausdrücke, die als NULL-Werte ausgewertet werden, werden nicht unterstützt.

Segment eliminierung

Datentypauswahlen haben möglicherweise erhebliche Auswirkungen auf die Abfrageleistung basierend auf allgemeinen Filterprädikaten für Abfragen im Columnstore-Index.

In Spaltenspeicherdaten bestehen Zeilengruppen aus Spaltensegmenten. Es gibt Metadaten mit jedem Segment, um eine schnelle Eliminierung von Segmenten zu ermöglichen, ohne sie zu lesen. Diese Segmentlöschung gilt für numerische Datentypen, Datums- und Uhrzeitdatentypen und den Datentyp "datetimeoffset" mit einer Skalierung kleiner oder gleich zwei. Ab SQL Server 2022 (16.x) werden die Funktionen zur Segmentlöschung auf Zeichenfolgen, binäre, guid-Datentypen und den Datentyp „datetimeoffset“ für die Skalierung größer als zwei erweitert.

Nach dem Upgrade auf eine Version von SQL Server, die die Eliminierung von Zeichenfolgen min/max (SQL Server 2022 (16.x) und höher unterstützt, profitiert der Spaltenspeicherindex dieses Feature erst, wenn es mit einer NEUERSTELLUNG oder DROP/CREATE neu erstellt wird.

Die Segmententfernung gilt nicht für branchenspezifische Datentypen, z. B. die Länge des Datentyps (max).<

Derzeit unterstützt nur SQL Server 2022 (16.x) und höher die Eliminierung gruppierter Spaltenspeicherzeilengruppen für das Prädikat LIKE , z. B column LIKE 'string%'. . . Segment eliminierung wird für nicht präfixige Verwendung von LIKE, z column LIKE '%string'. B. nicht unterstützt.

In Azure Synapse Analytics und ab SQL Server 2022 (16.x) können Sie geordnete gruppierte Spaltenspeicherindizes erstellen, die das Sortieren nach Spalten ermöglichen, um die Segmentausscheidung zu unterstützen, insbesondere für Zeichenfolgenspalten. In geordneten gruppierten Columnstore-Indizes ist die Segmentausscheidung für die erste Spalte im Indexschlüssel am effektivsten, da sie sortiert ist. Leistungsgewinne aufgrund der Segmentierung anderer Spalten in der Tabelle sind weniger vorhersagbar. Weitere Informationen zu sortierten gruppierten Columnstore-Indizes finden Sie unter Verwenden eines sortierten gruppierten Spaltenspeicherindex für große Data Warehouse-Tabellen.

Mit der Abfrageverbindungsoption SET STATISTICS IO können Sie die Segmentlöschung in Aktion anzeigen. Suchen Sie nach der Ausgabe, z. B. wie die folgende, um anzugeben, dass die Segmentausscheidung aufgetreten ist. Zeilengruppen bestehen aus Spaltensegmenten, sodass dies auf eine Segmentausscheidung hinweisen kann. Das folgende SET STATISTICS IO-Ausgabebeispiel für eine Abfrage wurde von der Abfrage ungefähr 83 % übersprungen:

...
Table 'FactResellerSalesPartCategoryFull'. Segment reads 16, segment skipped 83.
...

Nächste Schritte