Teilen über

Columnstore-Indizes: Abfrageleistung

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

Dieser Artikel enthält Empfehlungen zum Erreichen der schnellen Abfrageleistung mit Columnstore-Indizes.

Columnstore-Indizes können bis zu 100 Mal bessere Leistung bei Analyse- und Data Warehouse-Workloads erzielen und bis zu 10 Mal bessere Datenkomprimierung als herkömmliche Rowstore-Indizes. Diese Empfehlungen helfen Ihren Abfragen, die schnelle Abfrageleistung zu erzielen, die Spaltenspeicherindizes bereitstellen sollen.

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.

  • Wählen Sie sorgfältig die Reihenfolge ein. 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 die Anzahl der Zeilengruppen ermitteln, die als Teil der Abfrageverarbeitung ausgelassen werden.

  • Verwenden Sie einen gruppierten Rowstore-Index. Wenn sich das allgemeine Abfrage-Prädikat auf einer Spalte (z. B. ) befindet, C1die nicht mit der Einfügereihenfolge verknüpft ist, erstellen Sie einen gruppierten Rowstore-Index in Spalte C1. Legen Sie dann den gruppierten Index des Rowstores ab, und erstellen Sie einen gruppierten Spaltenspeicherindex. Wenn Sie den gruppierten Columnstore-Index explizit mithilfe MAXDOP = 1des gruppierten Spaltenspeicherindex erstellen, wird der resultierende Gruppierte Spaltenspeicherindex in Spalte C1perfekt sortiert. Wenn Sie angeben MAXDOP = 8, wird die Überlappung von Werten über acht Zeilengruppen hinweg angezeigt. Bei einem nicht gruppierten Columnstore-Index (NCCI) werden die Zeilen bereits vom gruppierten Index sortiert, wenn die Tabelle über einen gruppierten Index verfügt. In diesem Fall wird der nicht gruppierte Columnstore-Index ebenfalls automatisch sortiert. Ein Spaltenspeicherindex behält die Reihenfolge von Zeilen nicht inhärent bei. Wenn neue Zeilen eingefügt oder ältere Zeilen aktualisiert werden, müssen Sie den Prozess möglicherweise wiederholen, da sich die Analyseabfrageleistung verschlechtern kann.

  • Implementieren Sie die Tabellenpartitionierung. Sie können den Spaltenspeicherindex partitionieren und dann die Partitionslöschung verwenden, um die Anzahl der zu scannenden Zeilengruppen zu reduzieren. In einer Faktentabelle werden beispielsweise die Einkäufe von Kunden gespeichert. Ein gängiges Abfragemuster besteht darin, vierteljährliche Käufe nach zu finden.customer Kombinieren Sie in diesem Fall die Einfügereihenfolgespalte mit der Partitionierung der customer Spalte. Jede Partition enthält Zeilen für jeden customer, sortiert nach der Einfügung. Erwägen Sie außerdem die Verwendung der Tabellenpartitionierung, wenn ältere Daten aus dem Columnstore entfernt werden müssen. Das Aus- und Abschneiden von Partitionen, die nicht benötigt werden, ist eine effiziente Strategie zum Löschen von Daten ohne Fragmentierung.

  • Vermeiden Sie das Löschen großer Datenmengen. Das Entfernen von komprimierten Zeilen aus einer Zeilengruppe ist kein synchroner Vorgang. Es wäre aufwendig, eine Zeilengruppe zu dekomprimieren, die Zeile zu löschen und sie dann erneut zu komprimieren. Daher werden beim Löschen von Daten aus komprimierten Zeilengruppen diese Zeilengruppen weiterhin gescannt, obwohl sie weniger Zeilen zurückgeben. Wenn die Anzahl der gelöschten Zeilen für mehrere Zeilengruppen groß genug ist, um in weniger Zeilengruppen zusammengeführt zu werden, erhöht die Neuorganisation des Columnstores die Qualität des Indexes und die Abfrageleistung. Wenn ihr Datenlöschvorgang in der Regel ganze Zeilengruppen geleert, sollten Sie die Tabellenpartitionierung verwenden. Wechseln Sie Partitionen aus, die nicht mehr benötigt werden, und kürzen Sie sie, anstatt Zeilen zu löschen.

    Hinweis

    Ab SQL Server 2019 (15.x) wird der Tupel-Mover von einer Hintergrundzusammenführungsaufgabe unterstützt. Diese Aufgabe komprimiert automatisch kleinere OPEN Delta-Zeilengruppen, die seit einiger Zeit vorhanden sind, wie durch einen internen Schwellenwert bestimmt, oder führt KOMPRIMIERTe Zeilengruppen zusammen, 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 großer Datenmengen aus dem Spaltenspeicherindex erforderlich ist, sollten Sie diesen Vorgang im Laufe der Zeit in kleinere Löschbatches aufteilen. Die Batchverarbeitung ermöglicht es der Hintergrundzusammenführungsaufgabe, die Aufgabe zum Zusammenführen kleinerer Zeilengruppen zu verarbeiten und die Indexqualität zu verbessern. Danach ist es nicht erforderlich, nach der Datenlöschung indexreorganisationsfenster zu planen. Weitere Informationen zu Columnstore-Begriffen und -Konzepten finden Sie unter Columnstore-Indizes: Überblick

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 eine Million Zeilen enthält, verwendet SQL Server nur einen Thread, um den Spaltenspeicherindex zu erstellen.

Wenn Ihre Tabelle über mehr als eine Million Zeilen verfügt, SQL Server jedoch keine große Speichererteilung abrufen kann, um den Index mit MAXDOP zu erstellen, wird SQL Server bei Bedarf automatisch verringert MAXDOP . In einigen Fällen muss DOP auf eins reduziert werden, um den Index unter eingeschränkten Arbeitsspeicher in der verfügbaren Speichererteilung zu erstellen.

Seit 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 Analyseabfragen eine große Anzahl von Zeilen scannen, sind sie in der Regel I/O-gebunden und daher ist die Reduzierung von E/A während der Abfrageausführung für den Entwurf von Columnstore-Indizes von entscheidender Bedeutung. Sobald Daten in den Arbeitsspeicher gelesen wurden, ist es wichtig, die Anzahl der In-Memory-Vorgänge zu reduzieren.

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

Spaltenspeicherindizes erreichen bis zu 10 Mal mehr 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.

  • Spaltenspeicherindizes speichern Daten in komprimierter Form im Arbeitsspeicher, wodurch E/A reduziert wird, indem verhindert wird, dass dieselben Daten in den Arbeitsspeicher gelesen werden. Mit einer Komprimierung von 10 Mal können spaltengespeicherte Indizes beispielsweise 10 mal mehr Daten im Arbeitsspeicher speichern, verglichen mit dem Speichern der Daten in nicht komprimierter Form. Da mehr Daten im Arbeitsspeicher vorhanden sind, ist es wahrscheinlicher, dass der Spaltenspeicherindex die daten findet, die er im Arbeitsspeicher benötigt, ohne dass unnötige Lesevorgänge vom Datenträger entstehen.

  • 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 weisen immer denselben Datentyp auf und weisen tendenziell ähnliche Werte auf. Spaltenspeicher-Datenkomprimierungstechniken sind hervorragend geeignet, um höhere Komprimierungsraten zu erzielen, wenn Werte ähnlich sind.

Beispielsweise speichert eine Faktentabelle Kundenadressen und enthält eine Spalte für country-region. Die Gesamtzahl der möglichen Werte beträgt weniger als 200. Einige dieser Werte werden mehrmals wiederholt. Wenn die Faktentabelle über 100 Millionen Zeilen verfügt, wird die country-region Spalte einfach komprimiert und erfordert wenig Speicherplatz. Die Zeilen-nach-Zeilen-Komprimierung ist nicht in der Lage, die Ähnlichkeit von Spaltenwerten auf diese Weise zu groß zu machen, und muss mehr Bytes verwenden, um die Werte in der country-region Spalte zu komprimieren.

Spaltenlöschung

Columnstore-Indizes überspringen den Lesevorgang von Spalten, die für das Ergebnis der Abfrage nicht erforderlich sind. Die Spaltenlöschung reduziert die E/A-Abfrageausführung weiter und verbessert daher die Abfrageleistung.

  • 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 in einer ganzen Zeile lesen, um bestimmte Spaltenwerte abzurufen, wodurch E/A erhöht wird, da zusätzliche Daten unnötig 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. Es überspringt das Lesen in den anderen 45 Spalten, wodurch E/A um weitere 90 % reduziert wird, vorausgesetzt, alle Spalten weisen eine ähnliche Größe auf. Wenn dieselben Daten in einem Zeilenspeicher gespeichert werden, muss der Abfrageprozessor die verbleibenden 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 Zeilenspeicher oder B-Strukturindizes für einen gruppierten Spaltenspeicherindex erstellen. 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 Möglichkeit, Zeilengruppen zu überspringen, kann ein vollständiger Tabellenscan zeitaufwendig sein, insbesondere für große Tabellen.

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

Beispielsweise modelliert ein Einzelhandelsgeschäft seine Verkaufsdaten mithilfe einer Faktentabelle mit gruppiertem Spaltenspeicherindex. Jeder neue Verkauf speichert verschiedene Attribute der Transaktion, einschließlich des Datums, an dem ein Produkt verkauft wird. Interessanterweise werden Zeilen in dieser Tabelle in einer datumssortierten Reihenfolge geladen, auch wenn spaltengespeicherte Indizes keine sortierte Reihenfolge garantieren. Im Laufe 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 ist eine Verringerung der Datenmenge von 97 %, die in den Arbeitsspeicher gelesen und verarbeitet wird.

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 den Abfrageprädikatkriterien entspricht, wird die gesamte Zeilengruppe übersprungen, ohne dass tatsächlich E/A ausgeführt wird. Dies funktioniert, da die Daten in der Regel in einer sortierten Reihenfolge geladen werden. Obwohl die Zeilensortierung nicht gewährleistet ist, befinden sich ähnliche Datenwerte häufig innerhalb derselben Zeilengruppe oder einer benachbarten Zeilengruppe.

Weitere Informationen über Zeilengruppen finden Sie unter Richtlinien zum Entwerfen von Columnstore-Indizes.

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. Die Batchmodusverarbeitung funktioniert nach Möglichkeit auf komprimierten Daten und beseitigt einige der exchange-Operatoren, die von der Verarbeitung im Zeilenmodus verwendet werden, und beschleunigt Analyseabfragen nach Größenordnungen.

Nicht alle Abfrageausführungsoperatoren können im Batchmodus ausgeführt werden. Beispielsweise werden DML-Vorgänge (Data Manipulation Language, Datenmanipulationssprache) wie Einfügen, Löschen oder Aktualisieren jeweils jeweils eine Zeile ausgeführt. Batchmodusoperator wie Scan, Join, Aggregat, Sortierung und andere können die Abfrageleistung verbessern. Da der Columnstore-Index in SQL Server 2012 (11.x) eingeführt wurde, gibt es eine nachhaltige Initiative, um die Operatoren zu erweitern, die im Batchmodus ausgeführt werden können. In der folgenden Tabelle sind die Operatoren aufgeführt, die gemäß der Produktversion im Batchmodus ausgeführt werden.

Batchmodusoperatoren Verwendung SQL Server 2012 (11.x) SQL Server 2014 (12.x) SQL Server 2016 (13.x) und SQL-Datenbank1 Kommentare
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 Es wird ein Suchvorgang im Zeilenmodus durch einen nicht gruppierten B-Strukturindex durchgeführt.
Compute Scalar Ausdruck, dessen Auswertung einen Skalarwert ergibt. ja Ja ja Wie alle Batchmodusoperatoren gibt es einige Einschränkungen für den Datentyp.
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
sort 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-Datenbank 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.

Aggregatweitergabe

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, beginnend mit SQL Server 2016 (13.x), der Aggregatvorgang kann jedoch an den SCAN-Knoten übertragen werden. Aggregierter Pushdown verbessert die Leistung von Aggregatberechnungen um Größenordnungen über die Batchmodusausführung, 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 eine der folgenden Sein und muss in 64 Bit passen:
    • tinyint, int, bigint, smallint, bit
    • Smallmoney, Geld, Dezimalzahl und numerisch mit Genauigkeit <= 18
    • smalldate, date, datetime, datetime2, time

Beispielsweise erfolgt die aggregierte Pushdownfunktion in beiden der folgenden Abfragen:

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.

Tipp

Die Faktentabelle speichert die Unternehmensmessungen oder -transaktionen, und die Dimensionstabelle speichert die Dimensionen, anhand derer die Fakten analysiert werden müssen. Weitere Informationen zur dimensionalen Modellierung finden Sie unter Dimensional Modeling in Microsoft Fabric.

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 wird ProductCodehäufig als Zeichenfolge dargestellt. Für die Leistung von Abfragen empfiehlt es sich, Ersatzschlüssel zu erstellen, in der Regel eine ganzzahlige Spalte, um auf die Zeile in der Dimensionstabelle aus der Faktentabelle zu verweisen.

Der Columnstore-Index führt Analyseabfragen mit Verknüpfungen und Prädikaten aus, die numerische oder ganzzahlige Schlüssel effizient einbeziehen. SQL Server 2016 (13.x) verbesserte die Leistung von Analyseabfragen mit zeichenfolgenbasierten Spalten erheblich, indem die Prädikate mit Zeichenfolgenspalten an den SCAN-Knoten übertragen werden.

Zeichenfolgen-Prädikat-Pushdown nutzt das primäre/sekundäre Wörterbuch, das für Spalten erstellt wurde, um die Abfrageleistung zu verbessern. Betrachten Sie beispielsweise ein Zeichenfolgenspaltensegment innerhalb einer Zeilengruppe, das aus 100 unterschiedlichen Zeichenfolgenwerten besteht. Auf jeden eindeutigen Zeichenfolgenwert wird durchschnittlich 10.000 Mal verwiesen, wobei eine Million Zeilen vorausgesetzt wird. Bei einem Zeichenfolgen-Prädikat-Pushdown berechnet die Abfrageausführung das Prädikat anhand der Werte im Wörterbuch. Wenn das Prädikat qualifiziert ist, werden alle Zeilen, die auf den Wörterbuchwert verweisen, automatisch qualifiziert. Dies verbessert die Leistung auf zwei Arten:

  • Nur die qualifizierte Zeile wird zurückgegeben, um die Anzahl der Zeilen zu verringern, die aus dem Scanknoten fließen müssen.
  • Die Anzahl der Zeichenfolgenvergleiche wird reduziert. In diesem Beispiel sind nur 100 Zeichenfolgenvergleiche gegenüber einer Millionen Vergleiche erforderlich. Es gibt einige Einschränkungen:
    • Keine Zeichenfolgenprädikatweitergabe für Deltazeilengruppen. Es gibt kein Wörterbuch für Spalten in Deltazeilengruppen.
    • Keine Weitergabe von Zeichenfolgenprädikaten, wenn die Einträge im Wörterbuch eine Größe von 64 KB überschreiten.
    • Der Ausdruck, der Nullwerte auswertet, wird nicht unterstützt.

Segmenteliminierung

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

In Columnstore-Daten bestehen Zeilengruppen aus Spaltensegmenten. Es gibt Metadaten für jedes Segment, damit Segmente, ohne sie zu lesen, schnell eliminiert werden können. 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) erweitern sich Die Segmentlöschfunktionen auf Zeichenfolgen, binäre, GUID-Datentypen und den Datetimeoffset-Datentyp für die Skalierung größer als zwei.

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 Columnstore-Index dieses Feature erst, wenn es mit einem oder einem oder DROP/CREATEeinem .REBUILD

Die Segmenteliminierung gilt nicht für LOB-Datentypen, z. B. die (max.) Länge des Datentyps.

Derzeit unterstützen nur SQL Server 2022 (16.x) und höher für gruppierte Columnstore-Indizes die Zeilengruppenlöschung für das Präfix von LIKE-Prädikaten, z. B. column LIKE 'string%'. Die Segmenteliminierung wird für die Verwendung von LIKE ohne Präfix wie z. B. column LIKE '%string' nicht unterstützt.

Sortierte gruppierte Columnstore-Indizes profitieren auch von der Segmentausscheidung, insbesondere für Zeichenfolgenspalten. In geordneten gruppierten Columnstore-Indizes ist die Segmenteliminierung für die erste Spalte im Indexschlüssel am effektivsten, da sie sortiert ist. Leistungsgewinne aufgrund der Segmenteliminierung bei anderen Spalten in der Tabelle sind weniger vorhersagbar. Weitere Informationen zu sortierten gruppierten Columnstore-Indizes finden Sie unter Verwenden eines sortierten gruppierten Columnstore-Indexes für große Data Warehouse-Tabellen. Informationen zur Verfügbarkeit des sortierten Spaltenspeicherindexes finden Sie unter Verfügbarkeit des geordneten Spaltenindexes.

Mit der Abfrageverbindungsoption SET STATISTICS IO können Sie die Segmenteliminierung in Aktion ansehen. Suchen Sie nach der Ausgabe, z. B. der folgenden, um anzugeben, dass die Segmenteliminierung erfolgte. Zeilengruppen bestehen aus Spaltensegmenten, sodass dies auf die Segmentausscheidung hinweisen kann. Im folgenden SET STATISTICS IO Ausgabebeispiel einer Abfrage wurden ungefähr 83 % daten von der Abfrage übersprungen:

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

Zugehöriger Inhalt