MySQL执行ROLLBACK时并非卡死，而是InnoDB正单线程串行逆向遍历undo log链逐条恢复前镜像；该过程不可中断、不汇报进度、不响应KILL，且持续持有MDL锁和行锁，导致其他操作阻塞。
大事务回滚卡住，不是“没在动”，而是InnoDB正在逆向遍历undo log链做物理还原——这个过程不可中断、不汇报进度、也不响应KILL，看起来就像卡死。
为什么ROLLBACK命令发出去后长时间无响应
MySQL执行ROLLBACK时，并非简单地丢弃变更，而是要顺着undo log里的TRX_UNDO_INSERT_REC或TRX_UNDO_UPDATE_REC记录，逐条恢复前镜像。大事务产生的undo量可能达GB级，且必须单线程串行处理；期间它持续持有MDL锁和行锁，阻塞其他查询，但SHOW PROCESSLIST里状态常显示为Rolling back或Updating，没有百分比或ETA。
- undo log存放在独立表空间（
innodb_undo_directory指定路径），不与数据文件混放，磁盘IO瓶颈会直接拖慢回滚速度 - 回滚过程中
innodb_buffer_pool_size过小会导致频繁刷脏页，进一步拉长耗时 - 若事务涉及大量二级索引更新，回滚还要重建索引项，CPU和IO压力双高
用information_schema.INNODB_TRX查真实阻塞点
别只盯着TRX_STATE = 'ROLLING BACK'——这只能说明它在回滚，但无法判断是真卡住还是正常慢。关键要看它是否还在锁资源：
- 检查
TRX_ROWS_LOCKED和TRX_ROWS_MODIFIED：值极大（如超百万）说明确实是大事务回滚中 - 对比
TRX_STARTED和当前时间：若已运行数小时，但TRX_OPERATION_STATE仍是fetching rows或updating，大概率是undo链太长 - 重点看
TRX_MYSQL_THREAD_ID，用它去SHOW FULL PROCESSLIST确认该线程是否被其他事务阻塞（比如被一个未提交的SELECT ... FOR UPDATE锁住某行）
监控回滚进度的可行办法（非官方，但实测有效）
InnoDB本身不暴露回滚剩余量，但可通过间接指标估算：
- 查
information_schema.INNODB_METRICS中undo_log_truncated和undo_log_written的变化速率：若undo_log_written持续增长，说明undo还在被读取，回滚仍在进行 - 用
pt-kill配合--busy-time和--match-state过滤出长时间Rolling back的线程，再结合lsof -p <pid></pid>看mysqld进程是否在读ibdata1或undo文件，确认IO活跃 - 观察
SHOW ENGINE INNODB STATUS\G输出里的LOG段：Log sequence number和Last checkpoint at差值缩小，代表redo日志在回收，侧面反映回滚接近尾声
强行终止回滚的风险与替代方案
对已开始的回滚，KILL只会让连接断开，事务仍会在后台继续——这是InnoDB的设计机制，无法绕过。真正有效的干预点只有两个：
- 如果数据库还能连上，且确定该事务可丢弃：设
innodb_force_recovery = 3重启，跳过回滚阶段（注意此时所有未提交事务均被忽略，仅限紧急恢复） - 若磁盘空间不足导致回滚卡死：立刻清理
innodb_undo_directory下旧的undo表空间（需先停库），否则即使调大buffer pool也无济于事 - 日常预防比事后抢救更重要：业务层严格限制单事务影响行数（如
UPDATE ... LIMIT 10000），并用innodb_max_undo_log_size自动触发清理，避免undo膨胀失控
回滚不可见进度，是InnoDB事务原子性的代价。与其等它结束，不如从源头控制事务粒度——那才是最稳定的“监控”。
