仅当表含列存储索引、CPU支持AVX2且聚合字段非LOB或字符串聚合函数时，SQL Server 2022的聚合操作才启用批处理模式；行存储表（堆/B-tree）无论数据量多大或加hint均强制走行模式。
批处理模式对聚合加速有效，但仅当表有列存储索引、CPU支持AVX2、且聚合字段不含LOB或字符串聚合函数时才真正启用；普通行存储表（哪怕数据量极大）永远走行模式，加 hint 也无效。
哪些表能触发批处理模式聚合
批处理模式不是全局开关，而是执行计划中单个运算符的运行方式。它只在以下条件**全部满足**时出现：
- 目标表必须建有
CLUSTERED COLUMNSTORE INDEX，或带NONCLUSTERED COLUMNSTORE INDEX的行存储表（如堆或 B-tree 表） - CPU 必须支持 AVX2 指令集（Intel Haswell 及以后、AMD Excavator 及以后）
- 聚合运算符（如
Hash Aggregate、Stream Aggregate）必须出现在执行计划右侧“读取侧”，即紧邻扫描节点之后 - GROUP BY 和聚合字段不能是 LOB 类型（如
NVARCHAR(MAX)、VARBINARY(MAX)），也不能使用STRING_AGG或JSON_OBJECTAGG
常见误判：SELECT COUNT(*) FROM dbo.Orders（Orders 是普通聚集索引表）→ 始终行模式；SELECT COUNT(*) FROM dbo.Orders_CS（Orders_CS 有聚集列存储索引）→ 可能批模式，但必须查 XML 计划确认。
为什么加 OPTION(USE HINT('ALLOW_BATCH_MODE')) 没用
这个 hint 对聚合操作本身不生效，SQL Server 会直接报错 Msg 11533。它仅适用于某些扫描或连接场景（如列存储扫描 + 哈希连接），无法强制 Hash Aggregate 进入批模式。
- 优化器是否选批模式，取决于物理结构和数据类型，而非 hint
- 对行存储表执行
GROUP BY，即使加 hint，也会被拒绝编译 - 唯一可控路径是：建列存储索引 → 验证硬件 → 避免退化字段 → 查 XML 确认
BatchMode="true"
如何验证聚合真走批模式
图形执行计划里写“Batch Mode”不等于真启用——必须查 XML 计划中具体节点的 BatchMode 属性。
- 在 SSMS 中执行前先运行
SET STATISTICS XML ON - 搜索返回的 XML 中是否存在：
- 只要其中任一节点缺失
batchmode="true"，整个聚合链就未启用批处理加速 - 更高效的方式是查系统视图：
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%"'
聚合字段含 LOB 或 STRING_AGG 会怎样
哪怕表有聚集列存储索引、兼容级别 160、CPU 支持 AVX2，只要聚合涉及 NVARCHAR(MAX)、STRING_AGG 或 JSON_OBJECTAGG，执行计划里 Hash Aggregate 节点的 BatchMode 一定是 false。
- 这时你看到的性能提升，大概率来自列存储压缩减少 I/O，而非批处理向量化计算
- 字符串拼接类函数强制退化为行模式，因为批处理引擎无法处理变长、动态构造的输出结构
- 若业务必须用
STRING_AGG，建议拆分：先用批模式做数值/标识聚合，再用行模式做字符串拼接
最易被忽略的一点：批处理模式是否启用，和查询写法、统计信息、参数嗅探都无关，只取决于表结构、硬件能力与字段类型这三者是否同时达标。其他所有调优手段，都是在它失效前提下的补救。
