sql server 2019 行存储表聚合可启用批处理模式，但须满足兼容级别≥150、聚合列有有效统计信息、非禁用数据类型（如text/ntext）、避免nolock缺统计组合，且group by或order by top是可靠触发器；未满足任一条件则退化为行模式。

行存储表上的聚合（如 COUNT、SUM、AVG）在 SQL Server 2019 中能走批处理模式，但必须满足硬性条件——否则仍是逐行处理，性能无提升。

为什么你的 GROUP BY 没触发批处理模式？

批处理模式对行存储不是“默认开启”，它依赖优化器主动选择，而这个选择被以下几条规则卡死：

• 数据库兼容级别必须 ≥ 150：ALTER DATABASE [db_name] SET COMPATIBILITY_LEVEL = 150，低于此值直接忽略
• 聚合列不能是 TEXT、NTEXT、IMAGE 或未启用统计的 VARCHAR(MAX) 类型
• 必须有有效统计信息：哪怕只是 UPDATE STATISTICS [table_name]，缺了就退化为行模式
• 避免 NOLOCK 提示 + 缺失统计的组合，这会直接禁用批处理路径
• SELECT * + 聚合 + 无 WHERE 谓词，容易让优化器放弃批处理决策

GROUP BY 和 ORDER BY 是最可靠的批处理触发器

相比 JOIN，聚合类操作更容易进入批处理模式，尤其当配合排序或分组时：

• GROUP BY 列上有非空、高选择性统计（例如用户 ID、订单日期），效果更稳
• ORDER BY 后接 TOP N（如 ORDER BY amount DESC TOP 100）会显著提高触发概率——因为 TOP 是强向量化提示
• 避免在聚合后加 ORDER BY 无索引列，否则可能引入排序溢出，拖慢批处理收益
• 若需多列分组，优先把高基数列（如 order_id）放前面，低基数列（如 status）放后面，利于向量化分组哈希

怎么确认真的跑了批处理？别只看执行计划图标

图形执行计划里看到“Batch Mode on Rowstore”字样只是表面，真实运行状态得查动态视图：

• 执行完查询后，立即查：SELECT last_execution_type_desc, last_worker_time, last_logical_reads FROM sys.dm_exec_query_stats WHERE query_hash = ...，只有 last_execution_type_desc = 'BATCH' 才算真正生效
• 对比 last_worker_time：批模式下该值通常下降 30%~70%，但 last_logical_reads 可能不变甚至略升（因向量解压开销）
• 用 SET STATISTICS XML ON 查原始计划，搜索 BatchModeOnRowstore="true" 属性，而非只看运算符名称
• 如果聚合结果集很大但最终只取前几行，加 OPTION (USE HINT('ENABLE_BATCH_MODE')) 有时比等优化器自动选更可靠——但仅限统计准确、数据分布均匀时

最容易被忽略的是统计信息的时效性：哪怕刚建完索引，没更新统计，批处理照样不启动；另外，GROUP BY 后跟计算列（如 YEAR(order_date)）且无对应统计时，也会掉回行模式。