ROLLBACK不可中断且越拖越慢，因其必须串行重放undo日志、逐行恢复旧值、清理锁并刷脏页，耗时取决于TRX_ROWS_MODIFIED、undo大小及磁盘I/O性能。
因为回滚不是“撤销动作”，而是重放 undo 日志、逐行恢复旧值、清理锁、刷脏页的串行过程，耗时直接由修改行数、undo 大小和磁盘 I/O 决定。
ROLLBACK 为什么不可中断且越拖越慢
MySQL 执行 ROLLBACK 时，并不会跳过或并发加速任何步骤。它必须：读取每一条 undo 日志 → 恢复对应数据页上的旧值 → 清理该事务持有的所有行锁和意向锁 → 将修改过的页标记为脏页并最终刷盘。这个流程完全串行，无法跳过某条记录或绕过某个锁。
常见现象包括：
-
SHOW PROCESSLIST显示状态为Rolling back，但持续数分钟甚至小时 -
INFORMATION_SCHEMA.INNODB_TRX中TRX_STATE = 'ROLLING BACK'且TRX_ROWS_MODIFIED数值极大（比如 50 万+） - KILL 线程后状态变为
Killed，但TRX_STATE仍维持ROLLING BACK直到真正完成
执行快 ≠ 回滚快：关键差异在路径与资源
一条 UPDATE 批量改 10 万行可能只要 2 秒，是因为它走的是写入路径：定位行 → 更新内存页 → 记录 undo → 异步刷 log；而回滚必须走逆向路径：从 undo 日志里逐条读出旧值 → 定位原数据页 → 覆盖新值 → 清锁 → 刷脏页 —— 全部同步阻塞，且无法利用 buffer pool 缓存优化。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
影响回滚耗时的关键因素有：
-
TRX_ROWS_MODIFIED越大，undo 日志越多，扫描和重放开销越大 - undo 表空间若在机械盘上，
await高、%util接近 100%，I/O 成瓶颈 - 带外键约束或触发器的表，回滚还需额外做约束校验和级联操作
- 事务持有锁期间被其他事务反复访问，导致回滚阶段锁清理更复杂（尤其涉及 gap lock）
为什么 KILL 或重启都不能真正“停止”回滚
执行 KILL 只是给线程打标记，InnoDB 仍需完成当前 undo record 的回放才能退出。重启 MySQL 后，实例启动时会自动进入 crash recovery 阶段，重新加载未完成回滚的事务并继续执行——你省下的那几十分钟，大概率会在启动后原样还回来，甚至更久。
更危险的是：innodb_force_recovery > 0 或手动删除 ibdata1/undo_001 文件，等于放弃整个实例的数据一致性保障，除非你有可用的逻辑备份且能接受数小时恢复窗口，否则不具实操价值。
真正容易被忽略的一点是：回滚慢往往不是数据库的问题，而是事务本身设计失控的信号。一个修改 500 行就花 8 秒的事务，大概率裹挟了 HTTP 调用、日志写入或循环内未提交的子操作——这些在监控里看不到，却让 undo 堆积、purge 滞后、锁长期不释放。
