UPDATE语句默认自动包裹为单事务，必须完整记录每行变更的undo log（旧值）和redo log（新值），日志无法重用导致膨胀；关键须查log_reuse_wait_desc定位阻塞原因。
UPDATE语句默认走单事务，日志必须记全量变更
SQL Server、PostgreSQL（含WAL）、MySQL InnoDB 在执行 UPDATE 时，只要没显式分事务，就自动包裹成一个完整事务。哪怕你只改 50 万行，日志也得存下这 50 万行的每一条旧值（用于回滚）和新值（用于崩溃恢复）。这不是“写得多”，而是“必须全记”——日志文件因此被撑爆，不是磁盘真没空间，而是日志空间无法重用。
log_reuse_wait_desc 不查清，收缩或改模式都是临时止痛
报错里那句“请参阅 sys.databases 中的 log_reuse_wait_desc 列”是唯一可靠入口。常见返回值有：
-
ACTIVE_TRANSACTION：有长事务卡住，比如应用开了BEGIN TRAN后异常退出，或 SSMS 窗口关了但事务没提交 -
LOG_BACKUP：完整模式下压根没做BACKUP LOG，日志永远不截断 -
AVAILABILITY_REPLICA：AlwaysOn 同步延迟，主库日志不敢回收
不查这个字段就去 DBCC SHRINKFILE 或切简单模式，大概率收缩失败，或收缩完秒满；切模式后若忘了切回完整，还会丢掉时间点恢复能力。
分批更新不是加个 LIMIT 就完事，顺序和边界必须可控
MySQL 支持 UPDATE ... ORDER BY id LIMIT 1000，但漏掉 ORDER BY 会导致同一批数据被反复处理；PostgreSQL 不支持 LIMIT 直接进 UPDATE，得靠 CTE 套一层；SQL Server 得用 TOP (N) + WHILE 循环。
关键细节：
- 每次必须按唯一、递增字段（如
id）排序，避免跳行或重复 - 别用
LIMIT 1000 OFFSET 1000：OFFSET 越大越慢，且并发更新时可能漏数据 - 循环末尾加
IF @@ROWCOUNT = 0 BREAK，否则 WHERE 条件没命中时会无限空转 - 高并发场景建议加
WAITFOR DELAY '00:00:00.01'，缓解锁争用
真正容易被忽略的是 VLF 和自动增长配置
即使你把事务拆小、备份也做了，日志文件仍可能缓慢膨胀——问题常出在底层虚拟日志文件（VLF）结构上。如果初始日志设太小（比如 10MB），又配成“每次增长 10%”，当文件涨到 50GB 时，一次增长就是 5GB，不仅浪费空间，还会导致 VLF 数量爆炸，拖慢日志备份和数据库启动速度。
生产环境应：
- 预估峰值日志用量（比如日均 DML 量 × 1.5），设合理初始大小（如 2GB）
- 自动增长单位设为固定值（如
512 MB），禁用百分比增长 - 禁用“限制最大大小”，除非你明确知道业务绝不会超出该阈值
日志文件不是越大越好，也不是越小越安全；它的健康度取决于是否能稳定截断、是否被合理管理，而不是单纯看 .ldf 文件占了多少 GB。
