根本原因在于日志无法截断，而非写入量大；必须先解决log_reuse_wait_desc阻塞（如log_backup、active_transaction等），再分批执行事务并确保及时提交，收缩仅是辅助手段。
直接结论：不能靠收缩日志文件来治本，必须拆分事务 + 控制日志截断条件。 日志暴涨不是“写多了”，而是“旧日志没法被重用”——只要日志没被截断（log truncation），哪怕你删了数据、提交了事务，空间也不会释放。
为什么 UPDATE 一跑就满日志
SQL Server 把整条 UPDATE 当作一个事务处理，哪怕只改 50 万行，也得在日志里记下每行的前像（old value）和后像（new value）。如果数据库是 FULL 恢复模式，又没做 BACKUP LOG，日志就永远卡在“等待备份截断”的状态，log_reuse_wait_desc 显示 LOG_BACKUP 或 ACTIVE_TRANSACTION。
常见现象包括：The transaction log for database 'xxx' is full、DBCC SQLPERF(LOGSPACE) 显示 Log Space Used (%) 接近 100%、sys.databases 中 log_reuse_wait_desc 非 NONE。
用 TOP + WHILE 分批更新（SQL Server 原生方案）
这是最稳妥、兼容性最好、且能精准控制锁粒度的方式。关键不是“快”，而是“每次只占一小块日志、提交后立刻释放”。
- 必须带
ORDER BY（如id），否则TOP可能重复扫同一组行 - 用
@@ROWCOUNT = 0判断退出，不能只靠WHERE条件——否则 WHERE 没命中时会无限循环 - 加
WAITFOR DELAY '00:00:00.01'缓解并发锁争用，尤其在 OLTP 环境下建议保留 - 别把
TOP (N)和ORDER BY分开写成子查询，SQL Server 不保证执行顺序，可能漏数据
示例：
WHILE (1=1)
BEGIN
UPDATE TOP (5000) users
SET status = 'active'
WHERE status = 'pending'
ORDER BY id;
IF @@ROWCOUNT = 0 BREAK;
WAITFOR DELAY '00:00:00.01';
END
查清日志无法截断的真实原因
分批更新只是缓解手段，如果日志持续膨胀，说明底层截断机制失效。必须先确认 log_reuse_wait_desc 是什么：
-
LOG_BACKUP→ 立即补上BACKUP LOG作业，不能只做BACKUP DATABASE -
ACTIVE_TRANSACTION→ 运行DBCC OPENTRAN找出最老未提交事务，看是不是应用端忘了COMMIT或ROLLBACK -
REPLICATION→ 检查 CDC 或事务复制是否延迟，sp_repltrans或sys.dm_repl_articles可辅助定位 -
NOTHING但日志仍不收缩 → 可能是BACKUP LOG后没触发检查点，手动执行CHECKPOINT再试DBCC SHRINKFILE
注意：DBCC SHRINKFILE 只能收缩到最近一次日志截断后的活动日志尾部，不是“一键清空”。强行收缩反而引发碎片和性能抖动。
别踩这些坑
很多“快速修复”方案实际埋雷：
- 临时切
RECOVERY SIMPLE→ 会丢失所有自上次完整备份以来的 PITR 能力，生产环境禁用 - 用
DUMP TRANSACTION WITH NO_LOG→ SQL Server 2008+ 已移除该语法，强行执行报错 - 盲目增大日志文件自动增长步长 → 只是延缓问题，且大步长增长会引发 I/O 尖峰
- 在索引列上无条件分批 → 如果
WHERE条件不走索引，每次扫描全表，IO 和 CPU 双爆
真正要盯住的，从来不是日志文件大小本身，而是 log_reuse_wait_desc 和 DBCC OPENTRAN 的输出——它们才是日志空间能否回收的唯一判决依据。
