批量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 这类功能正在后台默默吃掉你的日志空间。