事务日志暴涨主因是“未及时截断”叠加“单次写入量过大”；批量update在完整恢复模式下需记录前后像，且事务未提交或日志备份缺失时日志无法截断，导致堆积。
事务日志暴涨不是因为“更新多”，而是因为“没及时截断”+“单次写入量过大”——两者叠加，磁盘就告急。
为什么批量 UPDATE 会让日志文件疯长
SQL Server 在完整恢复模式下，每行 UPDATE 都要记前像（old value）和后像（new value），日志体积≈修改数据量 × 2～3 倍。更关键的是：只要这批 UPDATE 所在的事务没提交，或日志备份没运行，这部分日志就无法被截断（log truncation），只能堆积。
常见触发场景：
- 用单个事务包几万行 UPDATE：日志持续累积不释放，
DBCC OPENTRAN能查到它还“活跃”着 - 开了 CDC 或事务复制但
cdc.<i>capture_job</i>卡住，或日志备份作业被禁用/失败，导致日志“只进不出” - WHERE 条件没走索引，引擎被迫全表扫描+逐行判断+逐行记日志，实际写入日志量远超目标行数
- 表上有触发器、启用
READ_COMMITTED_SNAPSHOT或大量非聚集索引，每次更新都连带记录额外变更
如何控制日志增长：分批 + 索引 + 模式校准
核心是让“日志生成节奏”匹配“日志截断能力”。三件事必须同步做：
- 改用主键推进式分批：用
TOP (@batchSize)+WHERE id > @last_id ORDER BY id，确保每次只触达真实要改的行，避免全扫；别碰OFFSET/FETCH，它越往后越慢还加剧日志写入延迟 - 给 WHERE 字段建复合索引：比如
UPDATE t SET status='done' WHERE status='pending' AND updated_at ，就要建 <code>IX_t_status_updatedat（顺序不能错） - 确认恢复模式与备份策略对齐：如果不用 PITR（按时间点恢复），可临时切到
SIMPLE恢复模式（注意：这会断开 CDC 和日志传送）；若必须用FULL，则日志备份频率至少设为每 5–15 分钟一次，并验证log_reuse_wait_desc不是LOG_BACKUP
容易被忽略的硬性限制
有些问题不会报错，但会让日志控制失效：
-
DBCC LOGINFO返回的 VLF 数量超过 1000，会导致日志截断变慢、备份卡顿；此时收缩日志（DBCC SHRINKFILE）只是治标，真正要重建日志文件大小并预分配 - 日志文件放在与数据文件同一块机械盘上，WRITELOG 等待飙升，日志写入实际被拖慢，间接延长了日志驻留时间
- 批量更新前没跑
UPDATE STATISTICS，执行计划选错索引甚至退化成 Table Scan，日志量翻倍还不自知 - 存储过程中用
WHILE循环但没加TRY...CATCH，某一批失败后整个过程静默中断，@last_id状态丢失，重跑时漏数据或重复更新
最麻烦的不是日志大，是它大得“不可预测”：同一条 UPDATE 语句，在不同统计信息、不同并发负载、不同日志空间余量下，日志产出量可能差 5 倍。上线前务必在影子库压测，而不是靠经验值估算。
