SQL Server 2022中仅当表含聚集或非聚集列存储索引、CPU支持AVX2指令集、聚合运算符位于读取侧且字段非LOB类型时，GROUP BY等聚合操作才可能启用批处理模式；行存储表（堆/B-tree）始终走行模式。
SQL Server 2022 中的聚合操作（如 SUM、COUNT、AVG、GROUP BY）只有在满足列存储索引 + 硬件支持的前提下，才能自动启用批处理模式；直接对行存储表执行 GROUP BY 永远走行模式，无法加速。
哪些表能触发批处理模式聚合？
批处理模式不是开关，而是执行计划中运算符的运行方式。它只在以下条件同时满足时出现：
- 目标表（或子查询来源表）必须是
CLUSTERED COLUMNSTORE INDEX或带有NONCLUSTERED COLUMNSTORE INDEX的行存储表 - CPU 必须支持 AVX2 指令集（Intel Haswell 及以后、AMD Excavator 及以后）
- 查询中聚合运算符（如
Hash Aggregate、Stream Aggregate）出现在执行计划右侧“读取侧”，且计划 XML 中该节点含BatchMode="true" - 聚合字段不能是 LOB 类型（如
NVARCHAR(MAX)、JSON），否则退化为行模式
为什么 SELECT COUNT(*) FROM heap_table 不走批模式？
堆表或 B-tree 行存储表没有列式矢量结构，优化器根本不会考虑批模式路径。即使加 OPTION(USE HINT('ALLOW_BATCH_MODE'))，也会报错 Msg 11533 —— 这个 hint 对聚合本身无效，仅适用于某些扫描/连接场景。
常见误判点：
-
SELECT COUNT(*) FROM dbo.Orders（Orders 是普通聚集索引）→ 始终行模式，哪怕数据量千万级 -
SELECT COUNT(*) FROM dbo.Orders_CS（Orders_CS 有聚集列存储索引）→ 可能批模式，但需确认执行计划中Columnstore Index Scan和后续Hash Aggregate节点都带BatchMode="true" - 使用
STRING_AGG或JSON_OBJECTAGG→ 强制退化为行模式，因涉及字符串拼接与动态构造
如何验证聚合是否真走批模式？
别只看图形执行计划里有没有“批处理”字样，要查 XML：
SELECT query_plan FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp WHERE CAST(query_plan AS NVARCHAR(MAX)) LIKE '%BatchMode="true%"'
更直接的方式：在 SSMS 中执行带 SET STATISTICS XML ON 的聚合语句，搜索返回的 XML 中：
<relop logicalop="Aggregate" ... batchmode="true"></relop><relop logicalop="Columnstore Index Scan" ... batchmode="true"></relop>
只要其中任一节点缺失 BatchMode="true"，整个聚合链就未启用批处理加速。
聚合性能提升的关键不在写法，而在数据组织
你改不了 GROUP BY 语法，但可以决定数据怎么存。实测对比（1亿行销售明细）：
- 行存储表 +
GROUP BY product_id：平均耗时 8.4 秒，CPU 占用持续 100% - 同一张表建
CLUSTERED COLUMNSTORE INDEX后重跑：耗时降至 1.1 秒，执行计划显示Hash Aggregate和Columnstore Index Scan全部启用批模式
注意：列存储索引不支持主键/外键约束（除非用 NONCLUSTERED 辅助索引），也不适合高频率单行 UPDATE/INSERT 场景。如果你的聚合查询来自分析型负载，而写入是批量导入（如每小时一次 INSERT INTO ... SELECT），那列存储就是最直接有效的加速杠杆 —— 其他所有 hint、trace flag、配置项，在没列式结构的前提下，都是徒劳。
