列存储索引专为大范围扫描和聚合分析（如SUM、AVG、COUNT、GROUP BY）设计，适合扫描数十万行以上、聚合少数列、过滤条件落在高基数时间列或分区键上的查询，不适合点查（如WHERE ID = 123）。
列存储索引 对聚合分析（如 SUM、AVG、COUNT、GROUP BY）的加速效果显著，但不是“建了就快”。实际性能取决于数据组织方式、查询模式和维护策略。
列存储索引适合什么查询？
它专为大范围扫描设计，不适合点查（比如 WHERE ID = 123）。如果你的查询经常：
– 扫描几十万行以上
– 聚合少数几列（如按 SaleDate 分组求 SUM(Quantity)）
– 过滤条件落在高基数时间列或分区键上（如 WHERE SaleDate >= '2025-01-01'）
那 列存储索引 很可能带来 5–50 倍提速。
为什么插入顺序影响列存储索引性能？
列存储索引本身不维护行序，但 SQL Server 会把连续插入的数据打包进同一行组（rowgroup），每组最多 1048576 行。如果插入顺序和常用过滤列一致（例如按 SaleDate 递增插入），SQL Server 就能基于行组元数据跳过大量不匹配的行组——这叫行组消除（rowgroup elimination）。
常见错误现象：
– 查询加了 WHERE SaleDate BETWEEN '2025-06-01' AND '2025-08-31'，却仍扫描全部行组
– sys.dm_db_column_store_row_group_physical_stats 显示大量 COMPRESSED 行组的 deleted_rows 高，但 state_desc 仍是 COMPRESSED
解决建议：
– 新建表时，先按常用过滤列排序插入（如 INSERT INTO ... SELECT ... ORDER BY SaleDate）
– 已有堆表或聚集索引表，可先建行存储聚集索引（ON SaleDate），再删掉它并用 MAXDOP = 1 创建聚集列存储索引
– 避免用 MAXDOP > 1 并行建索引，否则行组内值范围会重叠，削弱行组消除能力
如何避免删除操作拖垮列存储索引？
从已压缩行组中删数据，不会立刻释放空间或跳过扫描——SQL Server 只是标记行逻辑删除，查询时仍需解压、过滤、再返回结果。这会导致 I/O 和 CPU 暴增。
容易踩的坑：
– 用 DELETE FROM Sales WHERE SaleDate 清理历史数据<br>– 后续聚合查询变慢，且 <code>sys.dm_db_column_store_row_group_physical_stats 中大量行组显示 DELETED 行数占比 > 10%
正确做法：
– 按时间列做表分区（如每月一个分区）
– 清理旧数据时，用 ALTER TABLE ... SWITCH PARTITION 切出旧分区，再 TRUNCATE TABLE 或直接删表
– 如果必须删，删完立即执行 ALTER INDEX ... REORGANIZE，触发行组合并（仅合并逻辑删除率高的行组）
非聚集列存储索引（NCCI）要不要加？
只有在你无法改动主表结构（比如已是聚集索引表，且不能重建为聚集列存储）时才考虑 NCCI。它比聚集列存储索引多一次查找开销，且不支持行组消除（除非底层表本身有序）。
使用前提：
– 表已有聚集索引，且该索引键与常用过滤/分组列高度相关（如聚集索引在 (CustomerID, SaleDate) 上）
– 查询只涉及少量列，且这些列都包含在 NCCI 中（避免回表）
– 写入频率低（NCCI 会显著拖慢 INSERT/UPDATE）
不推荐场景：
– 表是堆（heap）且没建任何聚集索引 → 先建合适的聚集索引，再建聚集列存储索引
– 查询常需 SELECT * 或大量非索引列 → NCCI 效果差，还占额外空间
