MySQL磁盘I/O持续过高主因是脏页刷新与日志刷盘策略失配：buffer_pool过小、sync_binlog=1、innodb_flush_log_at_trx_commit=1导致写放大；Innodb_buffer_pool_wait_free>0且脏页占比超70%即为高压信号，需调优参数并匹配存储性能。
MySQL 磁盘 I/O 持续过高，大概率不是慢查询或索引缺失导致的，而是脏页刷新机制与日志刷盘策略失配——尤其当 innodb_buffer_pool_size 过小、sync_binlog 设为 1、或 innodb_flush_log_at_trx_commit 为 1 时，写放大效应会直接把 IOPS 推到瓶颈。
查 Innodb_buffer_pool_wait_free 和脏页比例
这个状态值非零，就说明 buffer pool 里没空闲页可用了，InnoDB 被迫同步刷脏页来腾地方，引发密集随机写。不是“偶尔高”，而是“持续高”的典型信号。
- 执行
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free';，值 > 0 就得立刻关注 - 算脏页占比：
(Innodb_buffer_pool_pages_dirty / Innodb_buffer_pool_pages_total) * 100，超过 70% 属于高压区间 - 同时看
Innodb_buffer_pool_pages_flushed每秒增量，若稳定在几百甚至上千，说明刷新太频繁
盯紧 sync_binlog 和 innodb_flush_log_at_trx_commit
这两个参数共同决定事务提交时的磁盘刷写强度。设为 1 是最安全，但也是最伤 I/O 的组合——每个事务都强制刷 binlog + redo log 到磁盘。
-
sync_binlog = 1：每条事务写 binlog 后都fdatasync()，SSD 都扛不住高频小写 -
innodb_flush_log_at_trx_commit = 1：每条事务都刷 redo log，且不合并 - 线上建议折中：
sync_binlog = 500（批量刷） +innodb_flush_log_at_trx_commit = 2（刷到 OS cache），牺牲极小一致性换 I/O 可控性 - 注意：主从架构下改
sync_binlog不影响数据一致性，binlog dump 线程读的是文件系统缓存，不是磁盘实时内容
确认是否被 innodb_io_capacity 误限速
这个参数本意是告诉 InnoDB “你的存储有多快”，但它不是上限，而是后台刷新线程（page cleaner）的参考基准。设得太低，会导致脏页积压；设得太高，又可能抢前台请求的 I/O 带宽。
- RAID 10 + SSD 阵列，
innodb_io_capacity建议设为 2000～4000（不是拍脑袋，按实测 iostat 的 w/s 峰值 × 0.7） - 同时检查
innodb_io_capacity_max，它控制突发刷新上限，应设为innodb_io_capacity的 2 倍左右 - 如果用的是云盘（如腾讯云 CBS、阿里云 ESSD），注意其 IOPS 是“突发+基线”模型，
innodb_io_capacity应对齐基线值，否则后台刷脏会反复撞限速墙
别忽略 innodb_adaptive_flushing 的实际效果
开启自适应刷新后，InnoDB 会根据脏页增长速率和 LSN 差距动态调整刷脏节奏。但它的算法在高并发短事务场景下容易滞后，导致某几秒内集中爆发刷脏。
- 观察
Innodb_log_waits是否上升：> 0 表示 redo log space 不够用，触发强制刷盘，这是 I/O 毛刺主因之一 - 若
innodb_adaptive_flushing = ON仍频繁毛刺，可临时关掉，改用更平滑的innodb_adaptive_flushing_lwm = 10（脏页占比低于 10% 才降频） - 真正治本要配合调大
innodb_log_file_size：比如从 48M 提到 512M，能显著拉长 LSN 增长周期，减少刷 redo 触发频次
脏页刷新和日志刷盘不是孤立配置，它们互相牵制。最容易被忽略的点是：你调大了 innodb_buffer_pool_size，却忘了同步调高 innodb_io_capacity；或者改了 sync_binlog，却没验证 binlog dump 线程是否还跟得上主库节奏。I/O 高从来不是单点问题，而是一连串“合理但叠加”的配置共同作用的结果。
