SQL-Server-Columnstore anhand von Zeilengruppen untersuchen

Ein Columnstore-Index kann große Aggregationen beschleunigen und auf einer anderen Tabelle mit gleicher Zeilenanzahl enttäuschen. Häufig unterscheiden sich Zeilengruppen, gelesene Spalten und die Möglichkeiten, durch Filter Arbeit auszulassen. Die bloße Existenz eines Columnstore-Index erklärt diese Unterschiede nicht.

Columnstore passt besonders zum Lesen weniger Spalten über viele Zeilen mit anschließender Aggregation. Für einzelne gezielte Zugriffe ersetzt er einen schmalen Rowstore-Index nicht automatisch. Beginnen Sie deshalb mit Abfrageform und Schreiblast und prüfen Sie anschließend die tatsächliche physische Struktur.

Zeilengruppen als Belege lesen

Eine komprimierte Gruppe kann bis zu 1.048.576 Zeilen enthalten. Neue Daten gelangen möglicherweise zunächst in Rowstore-Deltagruppen und werden später komprimiert. Diese schreibgeschützte Abfrage untersucht eine vorhandene Faktentabelle.

-- Replace dbo.FactSales with the table being investigated.
SELECT i.name AS IndexName, rg.partition_number, rg.row_group_id,
       rg.state_desc, rg.total_rows, rg.deleted_rows,
       CAST(100.0 * rg.deleted_rows / NULLIF(rg.total_rows, 0)
            AS decimal(6,2)) AS DeletedPercent,
       rg.size_in_bytes, rg.trim_reason_desc
FROM sys.dm_db_column_store_row_group_physical_stats AS rg
JOIN sys.indexes AS i
  ON i.object_id = rg.object_id AND i.index_id = rg.index_id
WHERE rg.object_id = OBJECT_ID(N'dbo.FactSales')
ORDER BY rg.index_id, rg.partition_number, rg.row_group_id;

OPEN und CLOSED kennzeichnen Phasen des Deltaspeichers; COMPRESSED steht für spaltenorientierte Daten. Mehrere offene Gruppen sind nicht automatisch problematisch, insbesondere bei mehreren Partitionen oder parallelen Ladevorgängen. Beobachten Sie Entwicklungen statt nur einer Momentaufnahme.

Vergleichen Sie bei komprimierten Gruppen Gesamtzeilen, gelöschte Zeilen und Kürzungsgründe. Viele logisch gelöschte Zeilen können weiterhin Aufwand verursachen, obwohl sie nichts zum Ergebnis beitragen. Kleine Gruppen können aus Speichergrenzen, Wörterbuchdruck oder kleinen Eingaben entstehen. Ein NULL-Anteil bei einer leeren Gruppe vermeidet eine künstliche Division durch null.

Die Sicht benötigt versionsabhängige Diagnoserechte, beispielsweise VIEW DATABASE STATE bei älteren Versionen und VIEW DATABASE PERFORMANCE STATE ab SQL Server 2022. Verwenden Sie dafür eine geeignete Diagnoseverbindung, statt Anwendungsrechte pauschal zu erweitern.

Struktur und Abfragearbeit verbinden

Betrachten Sie eine monatliche Aggregation nach Produktkategorie.

-- Example report shape for an existing fact table.
SELECT ProductCategoryId, SUM(Revenue) AS Revenue
FROM dbo.FactSales
WHERE SaleDate >= '20260101' AND SaleDate < '20260201'
GROUP BY ProductCategoryId;

Columnstore kann unbenutzte Spalten auslassen und Segmente überspringen, deren Wertebereiche den Datumsfilter nicht erfüllen können. Diese Segmenteliminierung ist etwas anderes als ein B-Baum-Seek. Enthält jede Gruppe Daten aus der gesamten Historie, kann selbst ein schmaler Monatsfilter viele Gruppen berühren.

Prüfen Sie tatsächlichen Ausführungsplan und verfügbare Angaben zu gelesenen Segmenten. Vergleichen Sie gelesene und zurückgegebene Zeilen, Aggregation und Auslagerungen. Eine gute Kompressionsrate beweist keine geringe Lesearbeit. Auch Batch Mode allein bestätigt keine passende Datenanordnung.

Anordnung und Ladeverfahren beeinflussen die Segmentgrenzen. Eine sortierte Übergabeabfrage garantiert aber noch keine bestimmte endgültige physische Struktur. Prüfen Sie die entstandenen Gruppen und Lesezugriffe. Untersuchen Sie außerdem Joins, die vor der Aggregation große Zwischenmengen erzeugen; der Index repariert keinen fachlich falschen Viele-zu-viele-Join.

Wenn überwiegend einzelne Verkäufe gelesen werden, kann ein ergänzender Rowstore-Zugriff oder ein anderer Entwurf passen. Messen Sie den tatsächlichen Mix einschließlich Änderungen, nicht nur eine günstige SUM-Abfrage.

Ursachen vor flächiger Wartung beheben

Große Bulk-Batches können direkt komprimierte Gruppen erzeugen. 102.400 Zeilen sind eine wichtige Grenze im dokumentierten Bulk-Ladeverhalten. Entscheidend ist die wirksame Menge pro Zielpartition. Viele kleine Partitionen oder Ladeströme können eine große Datei in deutlich kleinere Gruppen aufteilen.

Häufige Kleinstladungen und Änderungen erhöhen möglicherweise Delta- und Löschaufwand. Fassen Sie Eingaben zusammen, soweit die Aktualitätsanforderung das erlaubt. Umgekehrt kann erzwungenes sofortiges Komprimieren jeder kleinen offenen Gruppe dauerhaft kleine komprimierte Gruppen erzeugen. Wartung braucht ein messbares Ziel.

Wählen Sie Reorganisation oder Neuaufbau erst nach Bestimmung des betroffenen Index, der Partitionen und des erwarteten Nutzens. Ein Neuaufbau verbraucht Rechenzeit, Speicher, Protokoll und temporären Platz und konkurriert mit Berichten. Versionsabhängige Hintergrundzusammenführungen können manche Zustände bereits selbst verbessern.

Erfassen Sie vorher und nachher Gruppenanzahl, wirksame Zeilen, Berichtsdauer, Leseaufwand und Ladedurchsatz bei vergleichbaren Zeiträumen. Die Verbesserung soll reale Abfragen entlasten und zugleich die Fristen der Datenzufuhr einhalten.

Technische Referenzen: Microsoft Learn: Columnstore overview · Microsoft Learn: Columnstore query performance · Microsoft Learn: Row group physical statistics.