innodb_io_capacity 控制 InnoDB 每秒最大随机 I/O 次数，影响脏页刷新节奏和 LRU 淘汰策略；设太高会压垮磁盘，太低则堆积脏页引发同步刷和锁等待。
innodb_io_capacity 是干啥的，不是越大越好
它告诉 InnoDB：「你每秒最多能做多少次随机 I/O」，主要影响脏页刷新（flush）节奏和 LRU 列表淘汰策略。值设太高，InnoDB 会激进刷脏页，可能压垮磁盘；设太低，又容易堆积脏页，触发同步刷（sync flush），导致 Waiting for table flush 或 Waiting for global read lock 等锁等待飙升。
常见错误现象：
— SHOW ENGINE INNODB STATUS 里 LOG 部分显示 pending log writes 持续不降
— innodb_buffer_pool_pages_dirty 长期高于 5%～10%
— innodb_page_cleaner_thread CPU 占用高但刷新效率低
实操建议：
• 先查磁盘真实随机写能力：SSD 一般 2000～8000，NVMe 可达 10000+，HDD 通常只有 100～200
• 设为磁盘 4K 随机写 IOPS 的 50%～75%，比如 NVMe 实测 12000 IOPS，就设 innodb_io_capacity = 8000
• 同时调 innodb_io_capacity_max = 2 * innodb_io_capacity，给突发负载留缓冲
• 不要盲目对标厂商标称值——实际业务混合读写下，有效随机写能力往往打 6 折
为什么只调 innodb_io_capacity 不够，还得配 innodb_lru_scan_depth
这个参数控制每次 LRU 列表扫描深度，决定多少脏页有机会被选中刷出。它和 innodb_io_capacity 是联动的：后者决定“刷多快”，前者决定“每次刷哪些”。两者不匹配，就会出现「想刷的页没扫到」或「扫到了却刷不动」。
使用场景：
— 缓冲池大于 32GB 且并发更新频繁
— 观察到 Innodb_buffer_pool_wait_free 值上升，说明 page cleaner 跟不上分配速度
实操建议：
• 默认值 1024 太保守，大内存实例容易成为瓶颈
• 建议设为 innodb_io_capacity / 4（向下取整到 256 的倍数），例如 innodb_io_capacity = 8000 → innodb_lru_scan_depth = 2048
• 过大会增加 buffer pool mutex 争用，反而拖慢查询；过小则脏页滞留时间拉长，加剧锁等待
高负载下锁等待还卡？检查 innodb_flush_neighbors 是否关对了
该参数控制刷脏页时是否连带刷相邻物理页（所谓“邻居页”）。开启时能提升顺序写吞吐，但 SSD/NVMe 上反而因无效 IO 增加延迟，间接拉长事务持有锁的时间。
常见错误现象：
— innodb_data_fsyncs 明显高于 innodb_data_writes
— SHOW PROFILE FOR QUERY 显示大量 query end 或 update 阶段耗时突增
— 锁等待集中在 UPDATE/DELETE 语句，尤其 WHERE 条件走二级索引
实操建议：
• SSD/NVMe 环境一律设 innodb_flush_neighbors = 0
• HDD 环境可保留默认值 1，但需确认磁盘队列深度（iostat -x 中 avgqu-sz）未长期 >2
• 修改后观察 Innodb_buffer_pool_pages_flushed 和 Innodb_data_fsyncs 的比值，理想应接近 1:1
别忘了监控和验证，否则调了也白调
参数改完不验证，等于在黑盒里拧螺丝。MySQL 不会告诉你「我刷得更顺了」，但会通过几个关键指标暴露真实效果。
实操建议：
• 必看三项实时指标：
– SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty'（目标：稳定在 5% 以下）
– SHOW GLOBAL STATUS LIKE 'Innodb_page_cleaner_waits'（目标：0 或极低）
– SELECT * FROM information_schema.INNODB_METRICS WHERE NAME IN ('buffer_pool_wait_free', 'log_os_log_written')（对比单位时间增量）
• 用 pt-stalk 抓锁等待尖峰时的 SHOW ENGINE INNODB STATUS，重点看 SEMAPHORES 和 TRANSACTIONS 部分是否有 os_waits 累积
• 真实业务压测比 sysbench 更可靠——特别是混合 OLTP 场景下，二级索引更新引发的隐式锁竞争，参数敏感度远超预期
真正难的不是算出那个数字，是判断磁盘在你的 workload 下到底「算不算忙」。同一块 NVMe，在纯写入和读写各半的负载下，有效 innodb_io_capacity 可能差一倍。
