sql server 2019 行存储表默认不启用批处理模式，需显式开启跟踪标志11256，并满足兼容级别≥150、含向量化操作、统计信息准确等条件，子查询还需重写为apply且估算行数超10000才可能触发batch mode on rowstore。
SQL Server 2019 中，行存储表（非列存）**默认不启用批处理模式**，所以即使你写了子查询，也不会自动获得批模式带来的加速——除非你主动打开开关。
必须启用行存储批处理模式（Trace Flag 11256）
SQL Server 2019 允许在行存储表上启用批处理模式，但这是隐藏功能，需显式开启：
- 全局启用：
DBCC TRACEON(11256, -1)（重启后失效，建议加到启动参数） - 会话级启用：
DBCC TRACEON(11256)（仅当前连接有效） - 仅对满足条件的执行计划生效：查询需含聚合、JOIN、窗口函数等可向量化操作；单层
SELECT *不触发 - 启用后，执行计划中会出现
Batch Mode on Rowstore标识，且运算符（如Hash Join、Aggregate）会显示EstimatedExecutionMode="Batch"
子查询必须被重写为 APPLY 才能参与自适应
原生 WHERE EXISTS (SELECT ...) 或 IN 子查询不会进入批模式优化路径。只有当优化器将其重写为 CROSS APPLY 或 OUTER APPLY，且满足以下条件时，才可能激活自适应联接和批处理加速：
- 数据库兼容级别必须是
150：ALTER DATABASE [db] SET COMPATIBILITY_LEVEL = 150 - 执行后清空缓存：
DBCC FREEPROCCACHE，否则旧计划继续复用 - 子查询侧（APPLY 右侧）实际返回行数 > 10000 且估算偏差 > 2 倍
- 执行计划中
Adaptive Join节点的Adaptive="true"属性为真（需开SET STATISTICS XML ON查看）
批模式对子查询性能的实际影响边界
批模式不是万能加速器，它对子查询的收益高度依赖数据形态和硬件：
- 只加速「向量化友好」操作：SUM/COUNT/AVG、HASH JOIN、FILTER，但对
NESTED LOOPS无提速作用 - 若子查询含
UPPER()、CONVERT()等标量函数，基数估计易失真，导致批模式选错算法——此时需补丁（如 KB4538497）或加ENABLE_QUERY_OPTIMIZER_HOTFIXES - 内存压力大时，批模式反而更耗内存；小结果集（
- 真正起效的前提是 CPU 多核 + 数据局部性好；SSD 对批模式收益影响不大，但 HDD 上延迟可能掩盖加速效果
最常被忽略的一点：即使开了 trace flag 11256，如果子查询没被重写成 APPLY，或者兼容级别没设对，执行计划里看到的 Batch Mode 标签也只是“画饼”——它根本不会运行在批模式下。
