MySQL执行ROLLBACK时并非简单撤销，而是单线程逆向遍历undo log链，逐条恢复前镜像，过程串行不可中断、不响应KILL、不汇报进度，伴随高IO与锁清理开销。
回滚不是“撤销”，是单线程重放undo log
MySQL执行ROLLBACK时，并不会丢弃已写的变更，而是InnoDB后台用**单线程**逆向遍历undo log链，逐条恢复前镜像。这个过程必须串行、不可中断、不响应KILL，且不汇报进度——你看到的“卡住”，其实是它正在随机读GB级undo页、写数据页、重建索引项、清理行锁和MDL锁。
常见错误现象：SHOW PROCESSLIST里状态长期为Rolling back；INFORMATION_SCHEMA.INNODB_TRX中TRX_STATE = 'ROLLING BACK'且TRX_ROWS_MODIFIED极大（比如80万+）；其他查询被阻塞，但SHOW ENGINE INNODB STATUS\G的TRANSACTIONS段查不到显式锁等待。
IO飙高是因为不可控写放大
回滚期间，MySQL一边读undo页，一边生成反向redo、刷脏页、清理二级索引项，所有动作都走磁盘路径。尤其当事务涉及大量索引更新时，CPU和IO会双高：iostat -x 1会显示%util == 100%且await > 20ms。
关键点：
-
innodb_buffer_pool_size调大基本无效——undo log存放在独立表空间（路径由innodb_undo_directory指定），不在buffer pool缓存范围内 -
innodb_force_recovery只在mysqld启动时跳过崩溃恢复阶段的自动回滚，对已运行的回滚进程完全无效 -
innodb_rollback_segments和innodb_undo_log_truncate不影响当前回滚速度；调小前者反而加剧串行化
CPU飙升常被误判为SQL问题，实则是purge滞后或锁清理开销
真正拖慢回滚的，往往是History list length过高（>5000）、TRX_STARTED时间过长、或TRX_ROWS_MODIFIED过大。这些指标说明undo积压严重、purge线程没跟上，或事务本身修改量过大。
容易踩的坑：
-
TRX_OPERATION_STATE = 'fetching rows'不代表在查表——它常指正在读undo page -
KILL [ID]后STATE变Killed但TRX_STATE仍为ROLLING BACK，这是正常行为，不代表没生效 -
KILL QUERY [ID]只会中断当前语句，后台回滚继续——必须用KILL [ID]
临时缓解只能降速，不能跳过
没有官方“限速回滚”开关，但可通过系统级干预降低IO冲击：
- 用cgroups v2限制
mysqld进程IO带宽，例如io.max = mysql 10M - 临时调低
innodb_io_capacity（机械盘设200，SATA SSD设800） - 回滚期间禁用
innodb_doublewrite = OFF，减少页写入量约15%–20% - 确保
innodb_max_dirty_pages_pct = 50（非默认90），防脏页堆积引发强制刷盘
最易被忽略的一点：回滚无法真正“加速”，只能靠提前预防——拆分事务、避免长事务持有锁、监控History list length、及时清理大事务，比等它卡住再救火有效得多。
