Freigeben über

Columnstore-Indizes: Abfrageleistung

  • Artikel

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

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 die Einfügereihenfolge sorgfältig aus. 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 von MAXDOP = 1 erstellen, wird der resultierende Index in der Spalte C1 perfekt 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 nach dem Schlüssel des gruppierten Index sortiert, wenn die Tabelle über einen gruppierten Rowstore-Index verfügt. In diesem Fall wird der nicht gruppierte Columnstore-Index ebenfalls automatisch sortiert. Ein 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 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 anhand von customer zu finden. Kombinieren Sie in diesem Fall die Einfügereihenfolgespalte mit der Partitionierung der Spalte customer. 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 komprimierter 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 die Tupelverschiebung von einem Hintergrundtask zum Mergen 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 Wartungsfenster zur Indexreorganisation 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 erhalten kann, um den Index mit MAXDOP zu erstellen, verringert SQL Server automatisch MAXDOP nach Bedarf. In einigen Fällen muss DOP auf eins reduziert werden, um den Index bei begrenztem Arbeitsspeicher in der verfügbaren Speicherzuweisung 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 aus Hochgeschwindigkeitsverarbeitung im In-Memory-Batchmodus und Techniken, die die Eingabe-/Ausgabe-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 zeilenweise Komprimierung kann die Ähnlichkeit der Spaltenwerte nicht auf diese Weise ausnutzen und muss mehr Bytes verwenden, um die Werte in der country-region-Spalte zu komprimieren.

Spaltenlöschung

Columnstore-Indizes überspringen das Lesen in Spalten, die für das Abfrageergebnis nicht erforderlich sind. Durch die Spaltenlöschung werden die E/A-Vorgänge für die Abfrageausführung weiter reduziert, um die Abfrageleistung zu verbessern.

  • Die Spaltenlöschung ist möglich, da die Daten nach Spalten organisiert und komprimiert sind. Im Gegensatz dazu werden beim Speichern von Daten Zeilen nach Zeile die Spaltenwerte in jeder Zeile physisch zusammen gespeichert und können nicht einfach voneinander 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 enthält und die Abfrage nur fünf dieser Spalten verwendet, ruft der Spaltenspeicherindex nur die fünf 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 Tabellenüberprüfungen stimmt ein großer Prozentsatz der Daten in der Regel nicht mit den Abfrage-Prädikatkriterien überein. Mithilfe von Metadaten kann der Spaltenspeicherindex das Lesen der Zeilengruppen überspringen, die keine Daten enthalten, die für das Abfrageergebnis erforderlich sind, ganz ohne tatsächliche E/A. Durch die sogenannte Zeilengruppenlöschung werden die E/A-Vorgänge für vollständige Tabellenscans weiter reduziert, um die Abfrageleistung zu verbessern.

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-Baum-Indizes können eine Abfrage mit einer Gleichheitsbedingung oder einer Bedingung 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 Einzelhandelsunternehmen seine Verkaufsdaten mithilfe einer Faktentabelle mit gruppiertem Columnstore-Index. 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 Sortierung 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 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 einer sortierten Reihenfolge geladen werden. Obwohl die Zeilensortierung nicht garantiert 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.

Batch-Modus-Ausführung

Die Batchmodusausführung verarbeitet Zeilen in Gruppen, in der Regel bis zu 900 gleichzeitig, um die Effizienz zu verbessern. Beispielsweise berechnet die Abfrage SELECT SUM(Sales) FROM SalesData den Gesamtumsatz aus der SalesData Tabelle. Im Batchmodus verarbeitet das Abfragemodul die Daten in Gruppen von 900 Zeilen. Dieser Ansatz reduziert die Metadatenzugriffskosten und andere Arten von Aufwand, indem sie über alle Zeilen in einem Batch verteilt werden, anstatt den Aufwand für jede Zeile zu verursachen. Darüber hinaus funktioniert der Batchmodus nach Möglichkeit mit komprimierten Daten und entfernt einige der im Zeilenmodus verwendeten Austauschoperatoren, was die Analyseabfragen erheblich beschleunigt.

Nicht alle Abfrageausführungsoperatoren können im Batchmodus ausgeführt werden. Beispielsweise werden DML-Vorgänge (Data Manipulation Language, Datenbearbeitungssprache) wie Einfügen, Löschen oder Aktualisieren jeweils zeilenweise 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.

Batch-Modus-Operatoren 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 er 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 an den SCAN-Knoten gepusht werden.
columnstore index scan (nicht gruppiert) SCAN ja ja ja ja
Indexsuche Nicht verfügbar Nicht verfügbar Nein Führt einen Suchvorgang über einen nicht gruppierten B-Strukturindex im Zeilenmodus aus
compute scalar Ausdruck, dessen Auswertung einen Skalarwert ergibt. ja ja ja Wie alle Batchmodusoperatoren gibt es einige Einschränkungen für den Datentyp.
concatenation 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 bei Joins: keine nicht übereinstimmenden Typ-Joins für nicht ganzzahlige Typen
merge join Nein Nein Nein
multi-threaded queries 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.

Aggregatpushdown

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 im Vergleich zur Batch-Modus-Ausfü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 unterschiedliches 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

Das Aggregatpushdown 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ädikat-Pushdown

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 Optimierung der Leistung von Abfragen empfiehlt es sich, Surrogatschlüssel zu erstellen, typischerweise eine Spalte vom Typ Ganzzahl, 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) verbessert die Leistung von Analyseabfragen mit zeichenfolgenbasierten Spalten erheblich, indem die Prädikate mit Zeichenfolgenspalten an den SCAN-Knoten weitergegeben werden.

Beim Zeichenfolgenprädikat-Pushdown wird das für Spalten erstellte primäre/sekundäre Wörterbuch genutzt, 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 Zeichenfolgenprädikat-Pushdown wird das Prädikat bei der Abfrageausführung anhand der Werte im Wörterbuch berechnet. 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:
    • Kein Zeichenfolgenprädikat-Pushdown für Deltazeilengruppen Es gibt kein Wörterbuch für Spalten in Deltazeilengruppen.
    • Kein Zeichenfolgenprädikat-Pushdown, wenn die Einträge im Wörterbuch eine Größe von 64 KB überschreiten
    • Der Ausdruck, der Nullwerte auswertet, wird nicht unterstützt.

Segmentlöschung

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 Spaltenspeicherindex nicht von diesem Feature, bis es mithilfe eines ALTER INDEX REBUILD oder CREATE INDEX WITH (DROP_EXISTING = ON)neu erstellt wird.

Die Segmentlöschung gilt nicht für Branchensystemdaten, 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 Eliminierung von Segmenten wird nicht für die Verwendung von LIKEohne Präfix, wie z. B. bei column LIKE '%string', unterstützt.

Sortierte Columnstore-Indizes profitieren außerdem von der Segmentlöschung, insbesondere bei Zeichenfolgenspalten. In geordneten Spaltenspeicherindizes ist die Segmentauslöschung der ersten Spalte im Indexschlüssel am effektivsten, da sie sortiert ist. Leistungsgewinne aufgrund der Eliminierung von Segmenten in anderen Spalten der Tabelle sind weniger vorhersehbar. Weitere Informationen zu sortierten Columnstore-Indizes finden Sie unter Verwenden eines sortierten Columnstore-Index für große Data Warehouse-Tabellen. Informationen zur Verfügbarkeit des geordneten Spaltenspeicherindexes finden Sie unter Verfügbarkeit des geordneten Spaltenspeicherindexes.

Mit der Abfrageverbindungsoption SET STATISTICS IO können Sie die Segmenteliminierung in Aktion ansehen. Suchen Sie nach der Ausgabe (z. B. der folgenden), um zu ermitteln, ob eine Segmentlöschung erfolgt ist. Zeilengruppen bestehen aus Spaltensegmenten, sodass dies auf eine Segmentlöschung hinweisen kann. Im folgenden SET STATISTICS IO Ausgabebeispiel einer Abfrage wurden ungefähr 83 % der Daten bei der Abfrage übersprungen.

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

Zugehöriger Inhalt