列存储索引提升聚合查询性能的关键在于实际启用批处理模式（Batch Mode）并确保谓词下推和行组消除生效，否则即使建有索引也几乎无加速效果。
聚合查询慢？先确认是否进了批处理模式
列存储索引本身不保证加速——关键看查询是否实际以batch mode执行。如果执行计划里看到Row Mode，哪怕表上有聚集列存储索引，性能也几乎没提升。
常见卡点：
- 数据库兼容级别低于 130：必须设为
ALTER DATABASE [db] SET COMPATIBILITY_LEVEL = 130或更高 - 查询含不支持批处理的运算符（如某些 CLR 函数、特定窗口函数嵌套）
- WHERE 条件用了无法下推的表达式（例如
UPPER(col) = 'X'），导致谓词无法在压缩层过滤 - 连接字段类型不一致（如
INTvsBIGINT），触发隐式转换，阻断批处理
验证方式：查看执行计划 XML，搜索 BatchMode="1"；或用 sys.dm_exec_query_plan 提取后检查 RelOp 节点属性。
行组消除失效时，聚合仍会扫全量数据
列存储靠行组元数据跳过无关数据块，但这个机制依赖数据在物理上按某列“自然聚簇”。如果按时间插入但常查 ProductID，行组内 ProductID 值高度混杂，就无法跳过任何行组。
实操建议：
- 建聚集列存储前，先按高频过滤/分组列排序插入：用
SELECT ... INTO #staging ORDER BY ProductID，再CREATE CLUSTERED COLUMNSTORE INDEX - SQL Server 2016+ 支持显式
MAXDOP = 1创建，强制单线程排序，避免多线程导致值重叠 - 若无法改插入顺序，可在建列存储前加一层行存储聚集索引（
CREATE CLUSTERED INDEX ON ProductID），再删掉它重建列存储——这会继承排序效果
注意：REORGANIZE 不会重新排序已存在的行组，只合并删除标记过多的行组。
别忽略字符串谓词下推的限制
聚合快，往往是因为字符串过滤（如 WHERE Status = 'Shipped'）被下推到列段解压前完成。但下推有前提：
- 只能用于等值比较（
=、IN），不支持LIKE '%abc'或> - 列不能是
TEXT/NTEXT，需为VARCHAR/NVARCHAR（且长度合理，超长可能退化） - 如果该列参与了计算列或视图定义，下推大概率失效
查证方法：运行查询后执行 SELECT * FROM sys.dm_db_column_store_row_group_physical_stats WHERE object_id = OBJECT_ID('YourTable')，观察 deleted_rows 和 size_in_bytes，若 deleted_rows 高但 size_in_bytes 未明显下降，说明谓词没下推成功，行组仍在被完整扫描。
非聚集索引 + 列存储组合使用时的陷阱
SQL Server 2016+ 允许在聚集列存储上建 B 树非聚集索引，这对点查（WHERE ID = 123）有用，但会拖慢聚合——因为优化器可能误选非聚集索引路径，导致回表+逐行扫描。
排查重点：
- 执行计划里是否出现
Index Seek+Key Lookup组合？这是典型误选信号 - 统计信息是否陈旧？列存储索引的统计信息默认不自动更新，需手动
UPDATE STATISTICS YourTable WITH FULLSCAN - 若聚合查询占主导，建议禁用非聚集索引的自动统计更新（
STATISTICS_NORECOMPUTE = ON），避免干扰优化器成本估算
真正影响聚合性能的，从来不是索引数量，而是数据在行组内的分布质量与查询谓词能否穿透压缩层——这两点比建多少索引都关键。
