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)）且无对应统计时，也会掉回行模式。
