大事务回滚时io打满源于不可控写放大，必须干预回滚行为本身：innodb_force_recovery仅启动时跳过自动回滚，对已运行回滚无效；安全中断需kill线程id（非kill query）；有效措施包括临时禁用innodb_doublewrite、调低innodb_max_dirty_pages_pct至50、增大innodb_log_file_size，并用cgroups限io带宽。
大事务回滚时磁盘IO打满，不是“慢”，而是“不可控写放大”——MySQL 会边读undo页、边生成反向redo、边刷脏页、边清理索引项，所有动作全走磁盘路径。此时强行限速或加IOPS治标不治本，必须干预回滚行为本身。
为什么innodb_force_recovery不能直接跳过回滚
很多人想用innodb_force_recovery=3跳过崩溃恢复阶段的回滚，但该参数只在mysqld启动时生效，且仅跳过未完成事务的**自动回滚**；如果事务已显式执行ROLLBACK或连接断开后由后台线程接管回滚，innodb_force_recovery完全不起作用。此时回滚进程已进入活跃状态，只能靠终止或降速。
如何安全中断正在运行的大回滚
确认回滚线程ID后，必须用KILL而非KILL QUERY：
- 先查回滚线程：
SELECT ID, USER, COMMAND, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE STATE LIKE '%rollback%'; - 对准
ID执行KILL [ID]（不是KILL QUERY [ID]），否则只中断当前语句，后台回滚仍继续 - 若
KILL后STATE仍为Rolling back，说明事务处于UNDO页扫描中，需等待几秒再查；极端情况可能需重启mysqld（确保innodb_fast_shutdown=0）
innodb_rollback_segments和innodb_undo_log_truncate没用
这两个参数控制的是undo表空间的分配与回收策略，不影响正在进行的回滚速度。调小innodb_rollback_segments反而可能让回滚更慢（并发段减少，串行化加剧）；开启innodb_undo_log_truncate只在回滚完成后才触发truncate，对运行中回滚零影响。真正能起效的是：
- 回滚前就设
innodb_log_file_size = 2G（需停库重建），避免回滚过程中频繁checkpoint导致日志切片和刷盘风暴 - 确保
innodb_max_dirty_pages_pct = 50（非默认90），防止回滚脏页堆积引发强制刷盘 - 禁用
innodb_doublewrite = OFF（仅限回滚期间临时设置），减少页写入量约15%–20%
回滚无法中断时，唯一可控的降速手段
没有官方“限速回滚”开关，但可通过系统级资源压制降低IO冲击：
- 用
cgroups v2限制mysqld进程的IO带宽（如io.max = mysql 10M），避免挤占其他服务 - 临时调低
innodb_io_capacity至200（机械盘）或800（SATA SSD），抑制后台预读和刷脏节奏 - 禁止
autocommit=1的新连接建立，防止新事务加重undo压力 - 注意：
SET GLOBAL innodb_change_buffering = 'none'无效——回滚不走change buffer路径
回滚IO本质是“单线程重放undo记录+同步刷盘”，它不像导入或复制那样可分片。最容易被忽略的是：回滚开始后，SHOW ENGINE INNODB STATUS里的History list length值仍在缓慢下降，不代表IO压力减轻——那只是undo段释放进度，实际磁盘负载可能正达峰值。
