批量UPDATE日志暴涨的根源是日志截断时机失控，而非修改行数多；在完整恢复模式下未及时日志备份会导致log_full报错，且UPDATE日志量远超INSERT，因每行修改至少生成2条日志并受非聚集索引影响可达3–5倍。

批量 UPDATE 日志暴涨，不是因为“改得多”。

真正原因是没有控制住日志截断时机。哪怕只更新 10 万行，在完整恢复模式下没做日志备份，照样会出现 log_full 报错。

为什么 UPDATE 比 INSERT 更容易撑爆日志？

UPDATE 的开销，不只是“把值改一下”这么简单。

它需要先读出旧值，再写入新值，同时还要保留回滚所需的信息。也正因为如此，每修改一行，通常至少会生成 2 条日志，比如 LOP_MODIFY_ROW + LOP_SET_BITS 或同类记录。

相比之下，INSERT 只需要记录插入这个动作即可。

尤其要注意，一旦更新涉及非聚集索引列，每一条索引项变更都会额外产生日志。最终实际写入的日志量，很可能达到数据行数的 3–5 倍。

• 日志增长快慢和行数关系不大，关键看事务持续时间与恢复模式是否匹配
• 简单恢复模式下，CHECKPOINT 后未提交的日志可被覆盖；完整模式下，必须靠 BACKUP LOG 才能释放空间
• 即使开了 READ_COMMITTED_SNAPSHOT，UPDATE 仍走完整日志路径，它只减少阻塞，不省日志

BULK UPDATE 不可行，但可用 BULK INSERT + SWITCH 替代

SQL Server 没有 BULK UPDATE 语句。

如果强行用 UPDATE ... FROM 做大表关联，本质上仍然是逐行日志。真正低日志的方案，是绕开 UPDATE。

• 建新表（结构同原表，但提前禁用所有非聚集索引）
• 用 BULK INSERT 把更新后数据灌入新表（需 TABLOCK + 最小化日志前提）
• 用 ALTER TABLE ... SWITCH 原子切换分区或整个表（瞬间完成，日志极少）
• 重建索引（此时日志压力可控，且可分批做）

注意：SWITCH 要求源表和目标表 schema 完全一致、无外键/约束冲突、且目标表为空；否则会失败，而不是静默降级。

真要原地 UPDATE，必须分批 + 显式 COMMIT

不要以为“加个 WHERE 就能少写日志”。

WHERE 条件再精准，只要事务没提交，所有已修改行的日志都必须保留。正确做法是用边界主键分片，而不是依赖 @@ROWCOUNT。

• 按 id BETWEEN @start AND @end 划分批次，每次处理 5000–10000 行
• 每批独立事务：BEGIN TRAN → UPDATE → COMMIT，不能包在一个大事务里
• 批次间加 WAITFOR DELAY '00:00:00.1' 缓解 tempdb 和日志写入争抢
• 避免在 UPDATE 中调用函数（如 GETDATE()）、子查询或 JOIN，它们会拖慢执行并放大日志

别忽略 CDC 和复制对日志的隐性消耗

如果数据库启用了 CHANGE DATA CAPTURE (CDC) 或事务复制，UPDATE 操作除了自身日志，还会额外生成 CDC 日志和分发器所需日志。

这类日志不会因为分批提交而减少，只会延迟截断。

• 查是否启用：SELECT name, is_cdc_enabled FROM sys.databases WHERE name = DB_NAME()
• CDC 表本身也受日志保护，清理 cdf_* 表需走 sys.sp_cdc_cleanup_change_table，不是删数据就行
• 临时停用 CDC（EXEC sys.sp_cdc_disable_db）可大幅降低日志压力，但会丢失变更历史

真正的卡点不在语法怎么写，而在于你是否确认了当前数据库的恢复模式，是否配好了日志备份周期，以及是否意识到 CDC 这类功能正在后台默默吃掉日志空间。

《夸克》非常好用的免费AI浏览器

下载APP查看