Leitfaden zum Entwerfen von Columnstore-Indizes

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

Allgemeine Empfehlungen für das Entwerfen von Columnstore-Indizes. Einige gute Entwurfsentscheidungen helfen Ihnen, die hohe Datenkomprimierung und Abfrageleistung zu erzielen, die Spaltenspeicherindizes bereitstellen sollen.

Voraussetzungen

In diesem Artikel wird davon ausgegangen, dass Sie mit der Columnstore-Architektur und -Terminologie vertraut sind. Weitere Informationen finden Sie unter Columnstore indexes - Overview (Columnstore-Indizes: Übersicht) und Columnstore Index Architecture (Columnstore-Indizes: Architektur).

Informationen zur Datenanforderungen

Bevor Sie einen Columnstore-Index erstellen, sollten Sie Ihre Datenanforderungen so gut wie möglich kennen. Überlegen Sie sich beispielsweise die Antworten auf die folgenden Fragen:

• Wie groß ist Ihre Tabelle?
• Werden mit meinen Abfragen überwiegend Analysen durchgeführt, bei denen große Wertebereiche gescannt werden? Columnstore-Indizes sind für das Scannen großer Bereiche besser geeignet als für das Suchen bestimmter Werte.
• Werden im Rahmen Ihrer Arbeitsauslastung zahlreiche Aktualisierungen und Löschvorgänge durchgeführt? Columnstore-Indizes eignen sich gut für stabile Daten. Bei Abfragen sollten weniger als 10 % der Zeilen aktualisiert und gelöscht werden.
• Verfügen Sie über Fakten- und Dimensionstabellen für ein Data Warehouse?
• Müssen Sie Analysen für eine Transaktionsarbeitsauslastung ausführen? Wenn ja, lesen Sie die Richtlinien für den Columnstore-Entwurf für Echtzeit-Betriebsanalysen.

Möglicherweise benötigen Sie keinen Columnstore-Index. Zeilenspeichertabellen (oder B-Struktur) mit Heaps oder gruppierten Indizes führen am besten für Abfragen aus, die in die Daten suchen, nach einem bestimmten Wert oder nach Abfragen in einem kleinen Wertebereich suchen. Verwenden Sie Rowstore-Indizes für Transaktionsarbeitsauslastungen, da sie tendenziell eher Suchvorgänge in Tabellen als Scans umfangreicher Tabellen erfordern.

Auswählen des für Ihre Anforderungen am besten geeigneten Columnstore-Indexes

Ein Columnstore-Index ist ein gruppierter oder ein nicht gruppierter Index. Ein gruppierter Columnstore-Index kann über einen oder mehrere nicht gruppierte B-Strukturindizes verfügen. Sie können Columnstore-Indizes ganz einfach ausprobieren. Wenn Sie eine Tabelle als Columnstore-Index erstellen, können Sie diese problemlos wieder in eine Rowstore-Tabelle konvertieren, indem Sie den Columnstore-Index löschen.

Im Folgenden finden Sie eine Übersicht über die Optionen und Empfehlungen.

Columnstore-Option	Empfehlungen für die Verwendung	Komprimierung
Gruppierter Columnstore-Index	Verwendung für: 1) Herkömmliche Data Warehouse-Arbeitsauslastung mit einem Stern- oder Schneeflockenschema 2) Bei IoT-Arbeitsauslastungen (Internet der Dinge), bei denen mit minimalen Aktualisierungen und Löschvorgängen große Datenmengen eingefügt werden	Durchschnittlich zehnfach
Gruppierter Spaltenspeicherindex	Gilt für Azure Synapse Analytics und SQL Server 2022 (16.x) und höher Wird verwendet, wenn ein gruppierter Spaltenspeicherindex über einen einzelnen sortierten Prädikatspalten- oder Spaltensatz abgefragt wird. Diese Anleitung ähnelt der Auswahl der Schlüsselspalten für einen gruppierten Rowstore-Index, obwohl sich die komprimierten zugrunde liegenden Zeilengruppen anders verhalten. Weitere Informationen finden Sie unter CREATE COLUMNSTORE INDEX and Performance Tuning with ordered clustered columnstore index.	Durchschnittlich zehnfach
Nicht gruppierte B-Strukturindizes in einem gruppierten Spaltenspeicherindex	Verwenden Sie für Folgendes: 1. Erzwingen Sie Primärschlüssel- und Fremdschlüsseleinschränkungen für einen gruppierten Spaltenspeicherindex. 2. Beschleunigen Sie Abfragen, die nach bestimmten Werten oder kleinen Wertebereichen suchen. 3. Beschleunigen Sie Aktualisierungen und Löschungen bestimmter Zeilen.	Durchschnittlich zehnfach plus zusätzlicher Speicher für die nicht gruppierten Indizes
Nicht gruppierter Spaltenspeicherindex für einen datenträgerbasierten Heap- oder B-Strukturindex	Verwendung für: 1) Eine OLTP-Arbeitsauslastung mit einigen Analyseabfragen. Sie können für Analysen erstellte B-Strukturindizes löschen und durch einen nicht gruppierten Columnstore-Index ersetzen. 2) Zahlreiche herkömmliche OLTP-Arbeitsauslastungen, die ETL-Vorgänge (Extract Transform and Load) durchführen, um Daten in ein separates Data Warehouse zu verschieben. Wenn Sie einen nicht gruppierten Columnstore-Index erstellen, benötigen Sie bei einigen OLTP-Tabellen weder ETL-Vorgänge noch ein separates Data Warehouse.	Ein nicht gruppierter Columnstore-Index ist ein zusätzlicher Index, der im Durchschnitt einen um 10% größeren Speicher erforderlich macht.
Columnstore-Index in einer Speichertabelle	Dieselben Empfehlungen gelten für den nicht gruppierten Columnstore-Index in einer datenträgerbasierten Tabelle, wobei es sich bei der Basistabelle jedoch um eine In-Memory-Tabelle handelt.	Der Columnstore-Index ist ein zusätzlicher Index.

Verwenden eines Columnstore-Indexes für umfangreiche Data Warehouse-Tabellen

Der gruppierte Columnstore-Index ist nicht nur ein Index, sondern er ist der primäre Tabellenspeicher. Er erreicht beim Data Warehousing eine hohe Datenkomprimierung sowie eine deutlich bessere Abfrageleistung bei umfangreichen Fakten- und Dimensionstabellen. Gruppierte Columnstore-Indizes eignen sich weniger gut für Transaktionsabfragen, jedoch besonders gut für Analyseabfragen, da bei Analyseabfragen in der Regel Operationen für große Wertebereiche durchgeführt werden und nicht nach bestimmten Werten gesucht wird.

Überlegen Sie in folgenden Fällen, ob ein gruppierter Columnstore-Index sinnvoll ist:

• Jede Partition besteht aus mindestens einer Million Zeilen. Columnstore-Indizes enthalten in jeder Partition Zeilengruppen. Wenn die Tabelle zu klein ist, um eine Zeilengruppe in jeder Partition zu füllen, können Sie nicht von den Vorteilen der Columnstore-Komprimierung und Abfrageleistung profitieren.
• Abfragen führen in erster Linie Analysen für Wertebereiche durch. Bei einer Abfrage müssen beispielsweise alle Spaltenwerte gescannt werden, um den Durchschnittswert einer Spalte zu ermitteln. Anschließend werden die Werte durch Summieren gesammelt, um den Durchschnittswert zu ermitteln.
• Die meisten Einfügevorgänge werden für umfangreiche Datenvolumen mit minimalen Aktualisierungen und Löschvorgängen durchgeführt. Bei vielen Arbeitsauslastungen wie beim Internet der Dinge (Internet of Things, IOT) werden mit minimalen Aktualisierungen und Löschvorgängen große Datenvolumen eingefügt. Diese Workloads können von den Vorteilen der Komprimierung und Abfrageleistung profitieren, die von der Verwendung eines gruppierten Columnstore-Index stammen.

Verwenden Sie in den folgenden Fällen keinen gruppierten Columnstore-Index:

• Für die Tabelle sind varchar(max)-, nvarchar(max)- oder varbinary(max)-Datentypen erforderlich. Oder entwerfen Sie den Spaltenspeicherindex so, dass er diese Spalten nicht enthält (Gilt für: SQL Server 2016 (13.x) und frühere Versionen).

• Die Tabellendaten sind nicht dauerhaft. Überlegen Sie, ob die Verwendung einer Heap-Tabelle oder einer temporären Tabelle sinnvoll ist, wenn Sie die Daten schnell speichern und löschen müssen.

• Die Tabelle hat weniger als einer Million Zeilen pro Partition.

• Mehr als 10 % der Vorgänge in der Tabelle sind Aktualisierungs- und Löschvorgänge. Eine große Anzahl von Aktualisierungs- und Löschvorgängen führt zu einer Fragmentierung. Die Fragmentierung wirkt sich auf die Komprimierungsraten und die Abfrageleistung aus, bis Sie eine Reorganisation durchführen, bei der alle Daten in den Columnstore gezwungen werden und eine Defragmentierung durchgeführt wird. Weitere Informationen finden Sie unter Minimieren der Indexfragmentierung in Columnstore-Indizes.

Weitere Informationen finden Sie unter Columnstore-Indizes - Data Warehousing.

Verwenden eines sortierten gruppierten Columnstore-Index für große Data Warehouse-Tabellen

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

Erwägen Sie die Verwendung eines sortierten gruppierten Columnstore-Indexes in den folgenden Szenarien:

• Wenn Daten relativ statisch sind (ohne häufig geschriebene und gelöschte Daten), und der sortierte Gruppierte Spaltenspeicherindexschlüssel statisch ist, können sortierte gruppierte Spaltenspeicherindizes erhebliche Leistungsvorteile gegenüber nicht sortierten gruppierten Spaltenspeicherindizes oder gruppierten Indizes für analytische Workloads bieten.
• Je mehr unterschiedliche Werte in der ersten Spalte des gruppierten Spaltenspeicherindexschlüssels angegeben sind, desto besser sind die Leistungsgewinne für sortierte gruppierte Columnstore-Indizes. Dies liegt an einer verbesserten Segmentausscheidung für Zeichenfolgendaten. Weitere Informationen finden Sie unter Segment eliminierung.
• Wählen Sie einen sortierten gruppierten Spaltenspeicherindexschlüssel aus, der häufig abgefragt wird, und kann von der Segmententfernung profitieren, insbesondere von der ersten Spalte des Schlüssels. Leistungsgewinne aufgrund der Segmentierung anderer Spalten in der Tabelle sind weniger vorhersagbar.
• Anwendungsfälle, in denen nur die neuesten Analysedaten abgefragt werden müssen, z. B. die letzten 15 Sekunden, können sortierte gruppierte Columnstore-Indizes eine Segmentauslöschung für ältere Daten ermöglichen. Die erste Spalte im Schlüssel der sortierten gruppierten Spaltenspeicherdaten muss die Datums-/Uhrzeitdaten sein, z. B. ein eingefügtes oder erstelltes Datum/Uhrzeit. Die Segmententfernung wäre in einem sortierten gruppierten Columnstore-Index effektiver als in einem nicht sortierten gruppierten Columnstore-Index.
• Erwägen Sie geordnete gruppierte Columnstore-Indizes für Tabellen, die Schlüssel mit GUID-Daten enthalten, wobei der Eindeutigidentifizierer-Datentyp jetzt für die Segmentausscheidung verwendet werden kann.

Ein sortierter gruppierter Spaltenspeicherindex ist in diesen Szenarien möglicherweise nicht so effektiv:

• Ähnlich wie bei anderen Columnstore-Indizes könnte eine hohe Anzahl von Einfügeaktivitäten zu übermäßigen Speicher-E/A-Vorgängen führen.
• Bei Workloads, bei denen viele Schreibvorgänge vorhanden sind, wird die Qualität der Segmentlöschung im Laufe der Zeit aufgrund der Zeilengruppenwartung durch den Tupel-Mover reduziert. Dies kann durch regelmäßige Wartung des Columnstore-Indexes mit ALTER INDEX REORGANIZE abgemildert werden.

Hinzufügen eines nicht gruppierten B-Strukturindexes für effiziente Suchvorgänge in Tabellen

Ab SQL Server 2016 (13.x) können Sie nicht gruppierte B-Struktur- oder Rowstore-Indizes als sekundäre Indizes für einen gruppierten Columnstore-Index erstellen. Der nicht gruppierte B-Strukturindex wird bei Änderungen am Columnstore-Index aktualisiert. Diese leistungsstarke Funktion können Sie sich zunutze machen.

Mithilfe des sekundären B-Strukturindexes können Sie effizient nach bestimmten Zeilen suchen, ohne alle Zeilen scannen zu müssen. Auch weitere Optionen werden dadurch verfügbar. Beispielsweise können Sie eine Primär- oder Fremdschlüsseleinschränkung erzwingen, indem Sie eine UNIQUE-Bedingung auf den B-Strukturindex anwenden. Da ein nicht eindeutiger Wert nicht in den B-Strukturindex eingefügt werden kann, kann SQL Server den Wert nicht in den Columnstore einfügen.

Einen B-Strukturindex sollten Sie in folgenden Fällen in einem Columnstore-Index verwenden:

• Ausführen von Abfragen, die nach bestimmten Werten oder kleinen Wertebereichen suchen.
• Durchsetzen einer Einschränkung wie etwa einer Primärschlüssel- oder Fremdschlüsseleinschränkung.
• Effizientes Durchführen von Aktualisierungs- und Löschvorgängen. Mit dem B-Strukturindex können die Zeilen für Updates und Löschvorgänge schnell gefunden werden, ohne die Partition einer Tabelle oder die gesamte Tabelle scannen zu müssen.
• Ihnen steht zusätzlicher Speicherplatz zum Speichern des B-Strukturindexes zur Verfügung.

Verwendung eines nicht gruppierten Columnstore-Indexes für die Echtzeitanalyse

Ab SQL Server 2016 (13.x) können Sie einen nicht gruppierten Spaltenspeicherindex in einer auf einem Rowstore datenträgerbasierten Tabelle oder einer OLTP-Tabelle im Arbeitsspeicher verwenden. Dadurch ist es möglich, die Analyse für eine Transaktionstabelle in Echtzeit auszuführen. Transaktionen werden in der zugrunde liegenden Tabelle ausgeführt. Eine Analyse können Sie dagegen für den Columnstore-Index ausführen. Da beide Indizes von einer Tabelle verwaltet werden, sind Änderungen sowohl für Rowstore- als auch für Columnstore-Indizes in Echtzeit verfügbar.

Da mit einem Columnstore-Index im Vergleich zu einem Rowstore-Index eine zehnfach höhere Datenkomprimierung erzielt werden kann, ist nur wenig zusätzlicher Speicherplatz erforderlich. Während die komprimierte Rowstore-Tabelle beispielsweise 20 GB belegt, benötigt der Columnstore-Index nur 2 GB zusätzlich. Wie viel zusätzlicher Speicher erforderlich ist, hängt auch von der Anzahl der Spalten im nicht gruppierten Columnstore-Index ab.

Überlegen Sie in folgenden Fällen, ob ein nicht gruppierter Columnstore-Index sinnvoll ist:

• Ausführen von Analysen für eine Rowstore-Transaktionstabelle in Echtzeit Sie können vorhandene B-Strukturindizes ersetzen, die für die Analyse eines nicht gruppierten Columnstore-Indexes erstellt wurden.

• Ein separates Data Warehouse ist nicht erforderlich. Bisher haben Unternehmen Transaktionen für eine Rowstore-Tabelle ausgeführt und die Daten zur Analyse in ein separates Data Warehouse geladen. Bei vielen Arbeitsauslastungen sind der Ladevorgang und das separate Data Warehouse nicht mehr erforderlich, wenn ein nicht gruppierter Columnstore-Index für Transaktionstabellen erstellt wird.

SQL Server 2016 (13.x) bietet mehrere Strategien, um dieses Szenario auszuführen. Es lässt sich sehr einfach ausprobieren, da Sie einen nicht gruppierten Columnstore-Index ohne Änderungen an der OLTP-Anwendung aktivieren können.

Sie können die Analyse für eine lesbare sekundäre Datenbank ausführen, um zusätzliche Verarbeitungsressourcen hinzuzufügen. Bei Verwendung einer lesbaren sekundären Datenbank werden die Verarbeitung der Transaktionsarbeitsauslastung und die der Analysearbeitsauslastung voneinander getrennt.

Weitere Informationen finden Sie unter Erste Schritte mit Columnstore-Indizes für operative Echtzeitanalyse.

Weitere Informationen zur Auswahl des am besten geeigneten Columnstore-Indexes finden Sie im Blog Which columnstore index is right for my workload? (Welcher Columnstore-Index eignet sich für meine Arbeitsauslastung) von Sunil Agarwal.

Verwenden von Tabellenpartitionen für eine bessere Datenverwaltung und Abfrageleistung

Columnstore-Indizes unterstützen die Partitionierung, was eine gute Möglichkeit zum Verwalten und Archivieren von Daten ist. Durch die Partitionierung wird die Abfrageleistung verbessert, da Vorgänge auf eine oder mehrere Partitionen begrenzt werden.

Verwenden von Partitionen zur einfacheren Verwaltung von Daten

Bei umfangreichen Tabelle lassen sich Datenbereiche praktisch nur mithilfe von Partitionen verwalten. Die Vorteile von Partitionen für Rowstore-Tabellen gelten auch für Columnstore-Indizes.

Sowohl in Rowstore- als auch in Columnstore-Tabellen werden Partitionen in folgenden Fällen verwendet:

• Steuern der Größe von inkrementellen Sicherungen. Sie können Partitionen sichern, um Dateigruppen zu trennen und sie anschließend als schreibgeschützt zu kennzeichnen. Auf diese Weise werden die schreibgeschützten Dateigruppen bei zukünftigen Sicherungen übersprungen.
• Sparen bei Speicherkosten durch Verschieben älterer Partitionen in kostengünstigeren Speicher. Durch Partitionswechsel können Sie beispielsweise eine Partition an einen kostengünstigeren Speicherort verschieben.
• Effizientes Durchführen von Vorgängen durch Begrenzen der Vorgänge auf eine Partition. Sie können beispielsweise nur die fragmentierten Partitionen für die Indexwartung verwenden.

Zudem erreichen Sie mit der Partitionierung bei einem Columnstore-Index Folgendes:

• Sparen Sie weitere 30 % Speicherkosten. Ältere Partitionen können Sie mit den COLUMNSTORE_ARCHIVE-Komprimierungsoptionen komprimieren. Die Daten werden für die Abfrageleistung langsamer, was akzeptabel ist, wenn die Partition selten abgefragt wird.

Verwenden von Partitionen zum Steigern der Abfrageleistung

Mithilfe von Partitionen können Sie Ihre Abfragen auf das Scannen nur bestimmter Partitionen beschränken, wodurch die Anzahl der zu scannenden Zeilen begrenzt wird. Wenn der Index beispielsweise nach Jahr partitioniert ist und mit der Abfrage Daten aus dem letzten Jahr analysiert werden, müssen nur die Daten in einer Partition gescannt werden.

Verwenden von weniger Partitionen für einen Columnstore-Index

Ein Columnstore-Index zeigt die beste Leistung, wenn Sie im Vergleich zu einem Rowstore-Index weniger Partitionen verwenden, außer Sie verfügen über eine ausreichend große Datengröße. Wenn die Partitionen nicht jeweils mindestens eine Million Zeilen aufweisen, gelangen die meisten Zeilen in den Deltastore. Dort profitieren sie nicht von der Leistungssteigerung der Columnstore-Komprimierung. Wenn Sie beispielsweise eine Million Zeilen in eine Tabelle mit 10 Partitionen laden und jede Partition erhält 100.000 Zeilen, gelangen alle Zeilen in Delta-Zeilengruppen.

Beispiel:

• Laden Sie 1.000.000 Zeilen in eine Partition oder in eine nicht partitionierte Tabelle. Daraufhin erhalten Sie eine komprimierte Zeilengruppe mit 1.000.000 Zeilen. Dies ist für eine starke Datenkomprimierung und eine optimale Abfrageleistung nützlich.
• Laden Sie 1.000.000 Zeilen gleichmäßig in 10 Partitionen. Jede Partition erhält 100.000 Zeilen, also weniger als die Mindestanzahl für die Columnstore-Komprimierung. Daher kann der Columnstore-Index 10 Delta-Zeilengruppen mit je 100.000 Zeilen aufweisen. Es gibt Möglichkeiten, ein Ablegen der Delta-Zeilengruppen im Columnstore durchzusetzen. Wenn dies jedoch die einzigen Zeilen im Columnstore-Index sind, sind die komprimierten Zeilengruppen zu klein für eine optimale Komprimierung und Abfrageleistung.

Weitere Informationen zur Partitionierung finden Sie im Blogbeitrag Should I partition my columnstore index? (Sollte ich meinen Columnstore-Index partitionieren) von Sunil Agarwal.

Auswählen der geeigneten Datenkomprimierungsmethode

Der Columnstore-Index biete zwei Möglichkeiten für die Datenkomprimierung: die Columnstore-Komprimierung und die Archivkomprimierung. Sie können die Komprimierungsoption auswählen, wenn Sie den Index erstellen, oder sie später mit ALTER INDEX ändern ... NEUERSTELLEN.

Verwenden der Columnstore-Komprimierung für eine optimale Abfrageleistung

Mit der Columnstore-Komprimierung werden im Vergleich zu Rowstore-Indizes in der Regel zehnfach höhere Komprimierungsraten erzielt. Sie ist die Standardkomprimierungsmethode für Columnstore-Indizes und ermöglicht eine hohe Abfrageleistung.

Verwenden der Archivkomprimierung für eine optimale Datenkomprimierung

Die Archivkomprimierung ist in Fällen, in denen die Abfrageleistung eine untergeordnete Rolle spielt, für eine maximale Komprimierung vorgesehen. Sie erzielt im Vergleich zur Columnstore-Komprimierung höhere Datenkomprimierungsraten, hat jedoch ihren Preis. Die Komprimierung und Dekomprimierung der Daten dauert länger. Daher eignet sich diese Methode nicht für eine hohe Abfrageleistung.

Verwenden von Optimierungen beim Konvertieren einer Rowstore-Tabelle in einen Columnstore-Index

Wenn sich Ihre Daten bereits in einer Rowstore-Tabelle befinden, können Sie die Tabelle mit CREATE COLUMNSTORE INDEX in einen gruppierten Columnstore-Index konvertieren. Im Folgenden werden einige Optimierungen beschrieben, mit deren Hilfe sich die Abfrageleistung nach der Konvertierung der Tabelle verbessert.

Verwenden von MAXDOP zur Verbesserung der Zeilengruppenqualität

Sie können die maximale Anzahl von Prozessoren für die Konvertierung eines Indexes mit Heap-Struktur oder eines gruppierten B-Strukturindexes in einen Columnstore-Index konfigurieren. Verwenden Sie für die Konfiguration der Prozessoren die Option für den maximalen Grad an Parallelität (Maximum Degree of Parallelism, MAXDOP).

Wenn Sie über große Datenmengen verfügen, ist MAXDOP 1 wahrscheinlich zu langsam. MaxDOP wird erhöht, um einwandfrei zu 4 funktionieren. Wenn dies zu einigen Zeilengruppen führt, die nicht über die optimale Anzahl von Zeilen verfügen, können Sie ALTER INDEX REORGANIZE ausführen, um sie im Hintergrund zusammenzuführen.

Beibehalten der Sortierreihenfolge eines B-Strukturindexes

Da der B-Strukturindex Zeilen bereits in sortierter Reihenfolge speichert, können Sie die Abfrageleistung steigern, indem Sie diese beim Komprimieren der Zeilen im Columnstore-Index beibehalten.

Im Columnstore-Index werden die Daten nicht sortiert. Es werden jedoch Metadaten zum Überwachen der Mindest- und Höchstwerte der einzelnen Spaltensegmente in den jeweiligen Zeilengruppen verwendet. Beim Scannen eines Wertebereichs kann schnell berechnet werden, wenn eine Zeilengruppe übersprungen werden kann. Wenn die Daten sortiert werden, können mehr Zeilengruppen übersprungen werden.

So können Sie die Sortierreihenfolge bei der Konvertierung beibehalten:

• Verwenden Sie CREATE COLUMNSTORE INDEX mit der DROP_EXISTING-Klausel. Dadurch wird auch der Name des Indexes beibehalten. Wenn Sie Skripts verwenden, in denen der Name des Rowstore-Indexes enthalten ist, müssen Sie diese nicht aktualisieren.

  In diesem Beispiel wird ein gruppierter Rowstore-Index in einer Tabelle mit dem Namen MyFactTable in einen gruppierten Columnstore-Index konvertiert. Der Indexname ClusteredIndex_d473567f7ea04d7aafcac5364c241e09 bleibt unverändert.

  CREATE CLUSTERED COLUMNSTORE INDEX ClusteredIndex_d473567f7ea04d7aafcac5364c241e09
  ON MyFactTable
  WITH (DROP_EXISTING = ON);
  

Grundlegendes zur Segmententfernung

Jede Zeilengruppe enthält ein Spaltensegment für jede Spalte in der Tabelle. Jedes Spaltensegment wird zusammenhängend komprimiert und auf physischen Medien gespeichert.

Es gibt Metadaten mit jedem Segment, um eine schnelle Eliminierung von Segmenten zu ermöglichen, ohne sie zu lesen. Datentypauswahlen haben möglicherweise erhebliche Auswirkungen auf die Abfrageleistung basierend auf allgemeinen Filterprädikaten für Abfragen im Columnstore-Index. Weitere Informationen finden Sie unter Segment eliminierung.

Related Tasks

Hierbei handelt es sich um Aufgaben zum Erstellen und Verwalten von Columnstore-Indizes.

Aufgabe	Referenzartikel	Hinweise
Erstellen einer Tabelle als Columnstore.	CREATE TABLE (Transact-SQL)	Ab SQL Server 2016 (13.x) können Sie die Tabelle als gruppierten Spaltenspeicherindex erstellen. Sie brauchen nicht zuerst eine Rowstore-Tabelle zu erstellen, die Sie anschließend in Columnstore konvertieren.
Erstellen Sie eine In-Memory-Tabelle mit einem Columnstore-Index.	CREATE TABLE (Transact-SQL)	Ab SQL Server 2016 (13.x) können Sie eine speicheroptimierte Tabelle mit einem Columnstore-Index erstellen. Der Columnstore-Index kann auch nach dem Erstellen der Tabelle mit der ALTER TABLE ADD INDEX-Syntax hinzugefügt werden.
Konvertieren einer Rowstore-Tabelle in eine Columnstore-Tabelle.	CREATE COLUMNSTORE INDEX (Transact-SQL)	Konvertieren Sie einen vorhandenen Heap oder eine B-Struktur in einen Spaltenspeicher. Aus den Beispielen können Sie ersehen, wie vorhandene Indizes und der Name des Index beim Durchführen der Konvertierung behandelt werden.
Konvertieren einer Columnstore-Tabelle in einen Rowstore.	CREATE CLUSTERED INDEX (Transact-SQL) oder Convert a columnstore table back to a rowstore heap	In der Regel müssen Sie nicht konvertieren, allerdings kann es vorkommen, dass Sie diese Aktion durchführen müssen. Aus den Beispielen ist zu ersehen, wie ein Columnstore in einen Heap oder einen gruppierten Index konvertiert werden kann.
Erstellen eines Columnstore-Index für eine Rowstore-Tabelle.	CREATE COLUMNSTORE INDEX (Transact-SQL)	Eine Rowstore-Tabelle kann über einen Columnstore-Index verfügen. Ab SQL Server 2016 (13.x) kann der Spaltenspeicherindex eine gefilterte Bedingung aufweisen. In den Beispielen wird die grundlegende Syntax verwendet.
Erstellen leistungsfähiger Indizes für Betriebsanalysen.	Erste Schritte mit Columnstore für operative Echtzeitanalyse	Beschreibt, wie sich ergänzende Columnstore-Indizes und B-Strukturindizes erstellt werden, sodass OLTP-Abfragen B-Strukturindizes und Analyseabfragen Columnstore-Indizes verwenden.
Erstellen leistungsfähiger Columnstore-Indizes für Data Warehousing	Columnstore-Indizes - Data Warehousing	Beschreibt, wie B-Strukturindizes für Columnstore-Tabellen verwendet werden können, um leistungsstarke Data Warehousing-Abfragen zu erstellen.
Verwenden Sie einen B-Strukturindex, um eine Primärschlüsseleinschränkung für einen Columnstore-Index zu erzwingen.	Columnstore-Indizes - Data Warehousing	Zeigt, wie B-Struktur- und Columnstore-Indizes kombiniert werden können, um Primärschlüsseleinschränkungen für den Columnstore-Index zu erzwingen.
Löschen eines Columnstore-Index	DROP INDEX (Transact-SQL)	Beim Löschen eines Columnstore-Indexes wird die DROP INDEX-Standardsyntax verwendet, die auch für B-Strukturindizes verwendet wird. Beim Löschen eines gruppierten Columnstore-Index wird die Columnstore-Tabelle in einen Heap konvertiert.
Löschen einer Zeile aus einem Columnstore-Index	DELETE (Transact-SQL)	Verwenden Sie DELETE (Transact-SQL), um eine Zeile zu löschen. columnstore row: SQL Server markiert die Zeile als logisch gelöscht, aber gibt den physischen Speicher für die Zeile erst wieder zurück, wenn der Index neu erstellt wird. Deltastore-Zeile : SQL Server logisch und physisch löscht die Zeile.
Aktualisieren einer Zeile im columnstore-Index	UPDATE (Transact-SQL)	Verwenden Sie UPDATE (Transact-SQL), um eine Zeile zu aktualisieren. columnstore row: SQL Server markiert die Zeile als logisch gelöscht und fügt dann die aktualisierte Zeile in den Deltastore ein. Deltastore-Zeile : SQL Server aktualisiert die Zeile im Deltastore.
Durchsetzen, dass alle Zeilen im Deltastore in den Columnstore wechseln.	ALTER INDEX (Transact-SQL) ... WIEDER AUFZUBAUEN Neuorganisieren und Neuerstellen von Indizes	ALTER INDEX mit der REBUILD-Option erzwingt die Übernahme aller Zeilen in den Columnstore.
Defragmentieren eines Columnstore-Index	ALTER INDEX (Transact-SQL)	ALTER INDEX ... REORGANIZE defragmentiert Columnstore-Indizes online.
Zusammenführen von Tabellen mit Columnstore-Indizes.	MERGE (Transact-SQL)

Nächste Schritte

So erstellen Sie einen leeren Columnstore-Index für:

• SQL Server oder SQL-Datenbank finden Sie unter CREATE TABLE (Transact-SQL).
• Azure Synapse Analytics finden Sie unter CREATE TABLE (Azure Synapse Analytics).

Weitere Informationen zum Konvertieren eines vorhandenen Rowstore-Heaps oder B-Strukturindex in einen gruppierten Columnstore-Index oder zum Erstellen eines nicht gruppierten Columnstore-Indexes finden Sie unter CREATE COLUMNSTORE INDEX (Transact-SQL).

• Neuerungen in Columnstore-Indizes
• Columnstore-Indizes – Data Warehouse
• Columnstore-Indizes: Abfrageleistung