大事务回滚时磁盘IO打满,不是“慢”,而是“不可控写放大”——MySQL 会边读undo页、边生成反向redo、边刷脏页、边清理索引项,所有动作全走磁盘路径。此时强行限速或加IOPS治标不治本,必须干预回滚行为本身。 为什么innodb_force_recovery不能直接跳过回滚 遇到大事务回滚,

innodb_force_recovery不能直接跳过回滚遇到大事务回滚,很多人的第一反应是:能不能用innodb_force_recovery=3直接跳过?答案是,这个想法很美好,但现实很骨感。这个参数只在MySQL服务启动时生效,而且它跳过的仅仅是崩溃恢复阶段的**自动回滚**。如果事务已经显式执行了ROLLBACK,或者连接断开后由后台线程接管了回滚进程,那么innodb_force_recovery就完全无能为力了。此时,回滚已经成为一个活跃的后台任务,想让它停下来,只能靠外部终止或想办法给它降速。
长期稳定更新的攒劲资源: >>>点此立即查看<<<
确认了回滚线程之后,关键一步是:必须用KILL,而不是KILL QUERY。具体操作如下:
SELECT ID, USER, COMMAND, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE STATE LIKE '%rollback%';ID,执行KILL [ID]。这里要特别注意,如果误用了KILL QUERY [ID],只会中断当前正在执行的SQL语句,后台的回滚操作依然会继续。KILL后,线程的STATE仍然显示为Rolling backinnodb_fast_shutdown=0)。innodb_rollback_segments和innodb_undo_log_truncate没用别在这两个参数上浪费时间。它们控制的是undo表空间的分配与回收策略,对于**正在进行的**回滚速度,没有任何影响。调小innodb_rollback_segments甚至可能适得其反,因为回滚段减少会导致并发度下降,回滚可能更慢。而innodb_undo_log_truncate只在回滚彻底完成后才会触发清理动作,对运行中的回滚毫无帮助。真正能起到作用的,是下面这几项事前或事中的调整:
innodb_log_file_size设置为一个较大的值(例如2G,但这需要停库重建日志文件),目的是避免回滚过程中因日志空间不足而频繁触发checkpoint,从而引发刷盘风暴。innodb_max_dirty_pages_pct设置在50左右(而非默认的90),这能有效防止回滚产生的大量脏页在内存中堆积,从而避免触发强制性的激进刷盘。innodb_doublewrite(设置为OFF),这可以减少大约15%到20%的物理页写入量。当然,这仅限回滚期间临时操作,完成后务必恢复,以保证数据安全。MySQL并没有提供一个官方的“回滚限速”开关。当无法直接终止回滚时,唯一的思路是从系统层面进行资源压制,从而降低IO冲击:
cgroups v2限制mysqld进程的IO带宽(例如io.max = mysql 10M),这样可以避免回滚进程挤占其他关键服务的IO资源。innodb_io_capacity参数(例如机械盘调至200,SATA SSD调至800),这可以抑制InnoDB后台的预读和刷脏节奏,间接为回滚的IO操作“让路”。autocommit=1的连接,防止新事务产生额外的undo日志,加重系统压力。SET GLOBAL innodb_change_buffering = 'none'是无效的,因为回滚操作根本不走change buffer的路径。回滚的IO本质,是“单线程重放undo记录并同步刷盘”。它不像数据导入或复制那样可以并行分片。还有一个最容易被忽略的误区:回滚开始后,SHOW ENGINE INNODB STATUS中显示的History list length数值在缓慢下降,这并不代表IO压力在减轻——那仅仅表示undo段正在被释放,而实际的磁盘读写负载,很可能此时正达到峰值。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述