从库磁盘IOPS飙升主因是relay log、binlog（log_slave_updates=1时）和redo log三重刷盘叠加，尤其在sync_binlog=1与innodb_flush_log_at_trx_commit=1共用时，每事务落盘两次，再加relay log写入，IOPS易翻倍。
从库磁盘IOPS飙升，大概率不是因为主库写得多，而是从库自己在“反复刷盘”——尤其是sync_binlog=1和innodb_flush_log_at_trx_commit=1同时启用时，每条事务都要落盘两次（binlog + redo log），再叠加relay log写入，IOPS很容易翻倍甚至更高。
从库磁盘IOPS飙升的直接诱因：relay log + binlog + redo log三重刷盘
主从复制中，从库不只写relay log，还会在开启log_slave_updates=1时把执行过的SQL再写一遍binlog（用于级联复制），再加上InnoDB引擎自身的redo log刷新。三者叠加，尤其在批量导入或大事务回放时，IOPS会陡增。
-
relay_log写入：IO线程接收主库事件后，先写入本地relay log文件，这是顺序写，但频繁小事务会导致大量小IO -
binlog写入（如果启用了log_slave_updates）：SQL线程执行完后，还要把语句/行变更再记一次binlog，又是一轮刷盘 -
redo log刷新：每条事务提交都触发innodb_flush_log_at_trx_commit=1，强制刷盘，哪怕只是单行UPDATE
为什么机械硬盘或低配云盘会立刻打满？
SSD能扛住随机小IO，但机械硬盘或某些共享型云盘（如阿里云ESSD PL0/PL1）对avgrq-sz极敏感——iostat里看到avgrq-sz长期低于8 KB，说明全是小IO请求，IOPS数值会虚高，而吞吐（wMB/s）反而上不去。
- 从库SQL线程串行回放，无法像主库那样批量合并事务，导致
Blk_wrt/s（每秒写块数）暴涨 - 如果
relay_log_space_limit设得太小（比如默认0但磁盘空间紧张），IO线程会频繁flush并rotate relay log，进一步放大IO压力 - 用
pidstat -d 1 -p $(pgrep mysqld)看从库mysqld进程的Blk_wrt/s，若持续 > 5000，基本可判定是刷盘策略+硬件能力不匹配
别只盯着SQL线程，IO线程也在偷偷加压
很多人以为只有SQL线程消耗IO，其实IO线程拉日志时，如果主库binlog本身就是高频小事务生成的（比如sync_binlog=1 + 高频INSERT），从库IO线程收到的就是一堆Write_rows_event碎片，写relay log时无法合并，直接转成大量小IO。
- 用
show slave status\G观察Seconds_Behind_Master是否跳变剧烈：跳变+Read_Master_Log_Pos增长缓慢 → 主库I/O已饱和，IO线程拉不到新日志，但仍在反复尝试连接和写空relay log - 在从库执行
strace -p $(pgrep mysqld) -e trace=write,fsync -f 2>&1 | grep -E "(write|fsync)"，能看到大量fsync调用，说明刷盘动作密集 - 检查
show variables like 'relay_log_recovery'：如果为OFF且relay log损坏，从库重启后可能重拉全部日志，瞬间IOPS爆表
真正有效的缓解路径不是调参，而是拆IO压力源
盲目调低sync_binlog或innodb_flush_log_at_trx_commit会牺牲数据一致性，线上环境慎用。更稳妥的做法是物理隔离IO路径。
- 把
relay_log单独挂到一块高速盘（比如NVMe SSD），通过relay_log和relay_log_index参数指定路径，避免和datadir争抢IO - 关闭不必要的
log_slave_updates，除非真需要级联复制；若必须开，确保从库binlog也放在独立磁盘 - 确认
innodb_buffer_pool_size足够大（建议≥物理内存60%）：buffer pool太小会导致频繁page out/page in，间接抬高IO压力
最常被忽略的一点：从库IOPS飙升往往发生在主库压力正常时，问题不在“复制链路传输”，而在“从库本地执行与落盘”的节奏失衡——它不是管道堵了，是下游水龙头拧太紧还接了三个出水口。
