回滚慢的根本原因是undo log已提前写满，而非撤销动作本身复杂；其瓶颈在于顺序读undo log、随机写数据页和锁清理，三者均受磁盘io、数据离散度及purge阻塞制约。
回滚慢不是因为“撤销动作本身复杂”，而是事务执行过程中已经把 undo log 写满了——你看到的回滚延迟，其实是 undo log 的磁盘读取、数据页随机写入和锁清理在拖后腿。
回滚比提交慢的根本原因：undo log 已经提前写爆了
COMMIT 是轻量动作：刷 redo log、清理 undo 段、释放锁，大部分操作可异步或批量完成。ROLLBACK 却必须顺序读 undo log、逐行恢复旧值、随机写数据页、再清理锁——而这些 undo 记录早在你执行 ROLLBACK 前就已落盘，且很可能不在 buffer pool 里。
- 全表 UPDATE 100 万行 → 生成 100 万条 undo record，回滚就得重放这 100 万次逆操作
- 事务运行 8 分钟才出错 → undo 表空间可能已写满几百 MB，回滚时要从磁盘顺序读取，IO 成瓶颈
- 带外键或触发器 → 回滚还得校验约束、触发关联逻辑，额外开销不可忽略
为什么 KILL 一个正在回滚的事务反而更慢
MySQL 的 KILL 不会中断 undo 重放流程，只标记线程状态为 KILLED，线程仍得把当前正在处理的 undo page 刷完才能退出。你 KILL 一个已回滚 2 分钟、还剩 95% undo 要处理的事务，它大概率继续跑 15 分钟以上。
- 现象：
SHOW PROCESSLIST显示状态为Rolling back，但KILL后持续卡住 - 本质：不是锁等不到，是 undo I/O + 数据页写入 + 锁清理还没做完
- 风险：KILL 后若实例崩溃，crash recovery 会单线程重放全部未完成 undo，耗时可能翻倍
真正卡住回滚的三个硬瓶颈
别调 innodb_buffer_pool_size——它对回滚加速基本无效。真正起作用的是这三块：
-
undo表空间所在磁盘的随机读性能（SSD vs HDD，云盘 IOPS 是否打满） - 数据页修改的离散程度（大事务改散落在不同 page 的行 → 随机写放大）
- purge 线程是否被阻塞（
History list length> 5000 说明 purge 滞后，undo 积压）
用 iostat -x 1 看 await > 20ms 且 %util == 100%，基本能确认是磁盘 IO 卡死；查 SHOW ENGINE INNODB STATUS\G 里的 History list length，超 5000 就说明 purge 没跟上。
日常怎么避免掉进这个坑
回滚慢从来不是突发问题，是长事务 + 弱 IO + purging 配置僵化共同喂出来的。最容易被忽略的是：innodb_max_purge_lag = 0 在 MySQL 8.0 是默认值，等于关掉了 undo 堆积保护机制——它不自动 throttle 新事务，只等你靠监控和应用层兜底。
- 上线前必须设
innodb_undo_tablespaces >= 4（分散写入热点） - 应用层强制加事务超时：
innodb_lock_wait_timeout = 30，配合业务侧SET SESSION lock_wait_timeout = 30 - 批量更新一律用
UPDATE ... LIMIT 5000+ 循环提交，而不是单个事务吞全表
回滚不是数据库的撤销按钮，它是 undo log 的重放流水线。想让它快，得从源头控制日志量，而不是给流水线加宽厂房。
