直接拆成小事务并显式commit是唯一能同时缓解锁升级、日志暴涨和超时的通用解法，因为未结束事务会阻止日志截断、持续持有锁资源，导致log_reuse_wait_desc卡在active_transaction、日志使用率超90%、ssms卡死及锁升级阻塞其他操作。
直接拆成小事务并显式 COMMIT，是唯一能同时缓解锁升级、日志暴涨和超时的通用解法。
为什么不能让单个存储过程跑几百万行更新？
不是数据库“扛不住”，而是事务机制本身不允许：只要事务没结束，所有修改产生的日志就无法截断，log_reuse_wait_desc 会卡在 ACTIVE_TRANSACTION 或 LOG_BACKUP；同时锁资源不释放，容易触发锁升级（如从行锁升到表锁），阻塞其他操作。现象包括：Error: 9002、SSMS 卡在“正在执行”、DBCC SQLPERF(logspace) 显示日志使用率持续 >90%。
SQL Server 存储过程里怎么安全分批？
用 TOP + 有序主键推进，别碰 OFFSET/FETCH——后者每次都要扫描前 N 行，越往后越慢。关键点：
- 必须有
ORDER BY id，否则TOP (5000)行为不可预测 -
WHERE条件字段（如status = 'pending'）要建索引，否则每次都是全表扫描 - 每次更新后，用
SELECT @min_id = MIN(id) FROM table WHERE id > @min_id AND status = 'pending'刷新起点 - 加
IF @@ROWCOUNT = 0 BREAK防止空结果死循环 - 每批后跟
COMMIT，不要依赖隐式提交
MySQL 存储过程中如何避免变量残留导致漏处理？
MySQL 不支持带 LIMIT 的直接分页更新，常用变量模拟游标，但极易出错：
- 子查询里
@row_index必须配合ORDER BY id，否则顺序不保 - 每次执行前必须重置变量，比如
SET @row_index := -1，否则第二次会从上次结束位置继续 - 并发场景下可能漏行或重复处理，建议加
SELECT ... FOR UPDATE预占，或由应用层加分布式锁 - 别用
UPDATE ... LIMIT直接更新——它不保证按索引顺序执行，且无法跨语句复用偏移量
日志暴涨了，光收缩文件根本没用
收缩 .ldf 文件只是物理空间回收，前提是日志已截断。如果 log_reuse_wait_desc 是 REPLICATION 或 ACTIVE_TRANSACTION，收缩永远无效。先查 DBCC OPENTRAN 看有没有长事务；再查 sys.databases 的 log_reuse_wait_desc；若为 REPLICATION 却没真用复制，大概率是还原库遗留配置，得跑 sp_removedbreplication 清理。真正起效的操作永远在事务控制层，不在文件操作层。
