Pratique SQL Server

Diagnostiquer un columnstore SQL Server par groupes de lignes

Analysez états, lignes supprimées et raisons de réduction des groupes avant de modifier les chargements ou lancer une maintenance columnstore.

Un index columnstore peut accélérer une grande agrégation et décevoir sur une autre table de même taille. La différence se trouve souvent dans les groupes physiques, les colonnes lues et les possibilités d'éliminer du travail grâce aux filtres. Vérifier seulement la présence de l'index ne suffit pas.

Columnstore convient particulièrement à la lecture de quelques colonnes sur beaucoup de lignes pour agréger. Il ne remplace pas automatiquement un index rowstore étroit destiné aux recherches sélectives. Commencez par la forme des requêtes et les écritures, puis examinez la structure réelle.

Lire les groupes comme des indices

Un groupe compressé peut contenir jusqu'à 1 048 576 lignes. Les nouvelles données peuvent d'abord rejoindre des groupes delta en rowstore, avant compression. Cette requête en lecture seule inspecte une table de faits existante.

-- 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 et CLOSED représentent des étapes du delta store; COMPRESSED contient les données en colonnes. Plusieurs groupes ouverts ne signalent pas forcément un défaut, notamment avec plusieurs partitions ou flux de chargement. Observez leur évolution plutôt qu'un instant isolé.

Comparez total, suppressions logiques et raisons de réduction. Un groupe très marqué par les suppressions peut encore entraîner du travail pour des entrées inutiles au résultat. Un petit groupe peut venir d'une limite mémoire, d'une pression sur le dictionnaire ou d'une petite entrée. Un pourcentage NULL pour un groupe vide évite une division artificielle.

Les autorisations dépendent de la version, notamment VIEW DATABASE STATE sur les anciennes versions et VIEW DATABASE PERFORMANCE STATE à partir de SQL Server 2022. Utilisez une connexion de diagnostic autorisée sans élargir inutilement les droits applicatifs.

Relier la structure au travail de lecture

Prenons une agrégation mensuelle par catégorie.

-- 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 peut ignorer les colonnes inutilisées et sauter des segments dont les bornes ne satisfont pas le filtre de date. Cette élimination diffère d'une recherche dans un B-tree. Si chaque groupe couvre toute l'histoire, un mois étroit peut encore nécessiter beaucoup de lectures.

Examinez le plan réel et les diagnostics disponibles sur les segments. Comparez lignes lues et retournées, agrégation et débordements sur disque. Le taux de compression ne prouve pas que du travail a été évité. Le mode batch ne démontre pas non plus une disposition efficace.

L'organisation et les chargements influencent les bornes des segments, mais une requête intermédiaire triée ne garantit pas à elle seule la disposition finale. Vérifiez les groupes produits et les lectures du rapport. Contrôlez aussi les jointures créant de grandes quantités intermédiaires: l'index ne corrige pas une jointure plusieurs-à-plusieurs incorrecte.

Si les utilisateurs consultent surtout quelques ventes précises, un accès rowstore complémentaire ou un autre modèle peut mieux convenir. Mesurez le mélange réel, y compris insertions et modifications, plutôt qu'une seule requête SUM favorable.

Corriger la cause avant de tout reconstruire

Des chargements bulk suffisamment grands peuvent alimenter directement des groupes compressés. Le seuil de 102 400 lignes est important dans le comportement documenté. La taille réellement reçue par chaque partition compte. Répartir un grand fichier entre beaucoup de partitions ou de flux peut produire de petits groupes.

De minuscules chargements fréquents et des mises à jour répétées peuvent augmenter le travail des deltas et suppressions. Regroupez les entrées si la fraîcheur le permet. À l'inverse, forcer immédiatement la compression de chaque petit groupe ouvert peut figer une mauvaise granularité. La maintenance doit répondre à un objectif mesuré.

Choisissez réorganisation ou reconstruction après avoir identifié index, partitions, bénéfice et coût. Reconstruire consomme processeur, mémoire, journal et espace temporaire tout en concurrençant les rapports. Selon la version, des fusions de fond peuvent déjà améliorer certaines situations.

Mesurez avant et après les groupes, lignes utiles, lectures, durée et débit d'ingestion sur une période comparable. Une amélioration doit réduire le travail des rapports sans empêcher l'alimentation de respecter ses propres délais.

Références techniques: Microsoft Learn: Columnstore overview · Microsoft Learn: Columnstore query performance · Microsoft Learn: Row group physical statistics.

Question sur cet article

Vous avez une question sur ce sujet ?

Expliquez ce que vous évaluez ou le point qui vous bloque. Nous vous répondrons avec une recommandation pratique.

Inquiries are not enabled in this preview.

Poser une question sur cet article