-
我为了保证原子性把几万条记录的批量处理塞进了一个数据库事务,结果这个事务跑了好几分钟,期间长时间持锁阻塞了其他业务、占满了连接池、还把回滚段撑得老大、主从延迟飙升:一次大事务拖垮整个库的深度复盘
我有个批量任务要更新几万条记录,想着这些操作得保证原子性、要么全成功要么全回滚,就放进一个事务里:开启事务→循环几万次逐条 update→提交。功能没问题,可一上线跑,整个数据库就开始抖:其他业务大面积报锁等待超时、连接池被占满、主从延迟从毫秒飙到几十秒、DBA 告警 undo 暴涨。复盘才理解大事务的危害:一个事务在开始到提交的整个期间会持有它改过的行的锁、占用一个连接、在 undo log 里…- 3
- 0
-
MySQL UPDATE 8000 万行被 kill 后 rollback 90 分钟主库锁死 3 小时的真实事故复盘:InnoDB 回滚机制 + 拆批策略 + 10 条治理纪律
2026 年 2 月一次 UPDATE 8000 万行的合规任务跑了 4 小时,DBA 担心影响早高峰执行 KILL,结果 rollback 比正向执行更慢——花 90 分钟才完成,主库锁死 3 小时,业务超时 41 万笔,直接损失 80 万。复盘 InnoDB 回滚单线程机制 + 5 种大事务典型场景 + SafeBatchUpdater 框架 + 8 条工程纪律。- 4
- 0
大事务
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×