sql server 2022 中 dml 操作（insert/update/delete）本身不支持批处理模式执行，始终运行在行模式；批模式仅适用于查询计划中的特定读取运算符（如列存储扫描、哈希连接），且依赖列式数据结构与硬件支持。
SQL Server 2022 中 DML 操作本身不支持批处理模式执行 —— 这是常见误解的根源。 批模式（batch mode）仅在查询计划中出现于特定运算符（如 Hash Join、Columnstore Index Scan、Aggregate），且仅当满足硬件与数据结构前提时自动启用。DML 语句（INSERT、UPDATE、DELETE）的执行引擎始终运行在行模式（row mode），无论是否涉及列存储索引。
为什么 INSERT/UPDATE/DELETE 不走批模式？
批模式执行依赖两个硬性前提：一是数据以列式矢量格式组织（如列存储索引的压缩段），二是运算符支持矢量化处理（如 Batch Hash Aggregate）。而 DML 的写入路径必须逐行构造 delta store、维护 b-tree 或 rowgroup 状态、生成事务日志记录 —— 这些动作天然不具备矢量化条件。即使目标表是聚集列存储索引，INSERT INTO ... SELECT 中的 SELECT 部分可能用批模式扫描源表，但 INSERT 本身仍是行模式写入。
- 实测验证：查看执行计划 XML，搜索
BatchMode="true"，它只会出现在SELECT或MERGE的扫描/聚合节点，绝不会出现在Clustered Columnstore Insert或Index Insert运算符上 - 官方文档明确指出：“Batch mode execution is not used for DML operations”（SQL Server 2022 Docs, “Batch Mode Execution” section）
- 试图强制启用（如加
OPTION(USE HINT('ALLOW_BATCH_MODE'))）会直接报错：Msg 11533, Level 16: The hint 'ALLOW_BATCH_MODE' is not supported for this operation.
哪些 DML 场景能间接受益于批模式？
真正能“借到”批模式加速的，是 DML 语句中嵌套的 **读取部分**，尤其是大范围数据筛选与聚合。关键在于把计算压力从写入侧转移到读取侧。
-
INSERT INTO fact_sales_cs SELECT ... FROM staging_table WHERE ...：如果staging_table是列存储索引，且WHERE条件和GROUP BY能触发批模式扫描与聚合，则读取阶段可快数倍，整体 INSERT 耗时下降明显 -
MERGE语句中的USING子句：若源为列存储表，联接谓词下推 + 批模式哈希匹配可大幅减少中间结果集大小，降低后续插入/更新的行模式开销 - 带复杂子查询的
UPDATE：例如UPDATE t SET col = (SELECT AVG(x) FROM cs_table s WHERE s.id = t.id)，子查询若走批模式聚合，比行模式逐行查快一个数量级
高频 DML 下误信“批模式能加速写入”的典型坑
很多团队在升级到 SQL Server 2022 后，看到执行计划里出现 Batch Mode on Rowstore 就以为写入也能加速，结果在高并发 INSERT 场景中仍遭遇严重 PAGELATCH_EX 争用或日志写入瓶颈 —— 因为批模式对写入路径零影响。
- 混淆
BATCHSIZE和批模式：BULK INSERT ... WITH (BATCHSIZE=10000)是事务分批提交，和执行模式无关；它减少日志截断压力，但每批内部仍是行模式处理 - 误配兼容级别：即使数据库设为 160（SQL Server 2022），若表无列存储索引或 CPU 不满足 AVX2 指令集要求，批模式根本不会激活，读取部分也得不到加速
- 忽略硬件门槛：批模式在 SQL Server 2022 中默认要求 CPU 支持 AVX2；旧服务器（如 Intel Haswell 之前）即使建了列存储索引，也只走回退的行模式
真正要提速高频 DML，得放弃“让写入变快”的幻想，转而控制写入节奏（如用 MERGE + 临时表攒批）、卸载计算到读取侧、或彻底异步化（Service Broker / CDC）。批模式只是个高效的“读取加速器”，不是 DML 的银弹。
