innodb_io_capacity应根据存储类型合理设置：SSD设1000–3000，NVMe设4000–6000，HDD设200–400，并必须配置innodb_io_capacity_max为1.5–2倍以应对突发压力，同时需匹配innodb_write_io_threads和innodb_max_dirty_pages_pct等参数协同优化。
MySQL的innodb_io_capacity到底该设多大？
它不是越大越好，也不是照搬磁盘标称IOPS就行。这个值本质是InnoDB用来估算后台刷脏页、合并change buffer等IO任务“能干多快”的参考上限，设高了反而会让刷盘节奏失控，加剧IO毛刺。
常见错误现象：innodb_io_capacity设成2000甚至5000，但实际磁盘（比如一块普通NVMe）持续随机写也就10万IOPS，结果导致大量log file is full或Waiting for query cache lock类等待，其实是刷盘跟不上，日志循环被堵死。
- SSD（消费级）：实测稳定随机写IOPS通常在3万–8万之间，
innodb_io_capacity建议设为1000–3000（留余量，避免压满） - NVMe（企业级，如Intel D3700）：可设到4000–6000，但必须配合
innodb_io_capacity_max = 2 * innodb_io_capacity - HDD：别硬撑，200–400已是极限；若还卡，优先考虑换存储或调低
innodb_max_dirty_pages_pct
为什么innodb_io_capacity_max不能忽略？
它是innodb_io_capacity的“弹性上限”，当脏页积压严重或redo log快满时，InnoDB会临时冲高刷盘速度——但如果没有innodb_io_capacity_max兜底，就可能瞬间打爆IO队列，引发系统级延迟飙升。
使用场景：主库突发大事务、从库追主库延迟时，都依赖这个参数缓冲压力。
- 必须设，且推荐为
innodb_io_capacity的1.5–2倍（例如前者3000，后者设4500–6000） - 设为0或未配置？InnoDB会自动按
innodb_io_capacity的2倍算，但不可控，不建议依赖 - 线上变更后，观察
SHOW ENGINE INNODB STATUS里的Buffer pool hit rate和Pages flushed速率是否平稳
调整后IO没改善？先查这三个地方
IO瓶颈未必出在InnoDB参数上，innodb_io_capacity只是调度策略，不是IO加速器。很多情况下改了参数却没效果，是因为底层被卡住了。
- 检查
/proc/diskstats里对应设备的await和%util：如果await > 10ms或%util == 100%，说明磁盘本身已饱和，调参无意义 - 确认文件系统挂载选项：ext4要加
noatime,barrier=0,data=writeback（仅限数据库专用盘），XFS必须用noatime,logbufs=8,logbsize=256k - 看MySQL是否在用
O_DIRECT：确认innodb_flush_method = O_DIRECT（Linux下），否则OS缓存层会干扰InnoDB的IO节奏判断
并发写入高时，innodb_io_capacity和线程数怎么配？
单靠提高IO容量参数扛不住高并发写，必须配合IO线程资源释放。InnoDB默认只有4个写线程（innodb_write_io_threads），哪怕磁盘再快，线程不够也排不上队。
性能影响：线程数太少会导致log write pending和log flush pending时间上升，间接拖慢事务提交。
- SSD/NVMe：把
innodb_write_io_threads和innodb_read_io_threads都设为8–16（注意总数不超过CPU核心数×2） - 确保
innodb_adaptive_flushing = ON，否则固定刷盘节奏无法响应突发负载 - 不要只调
innodb_io_capacity而忽略innodb_max_dirty_pages_pct = 75–85，否则脏页堆积过深，单次刷盘压力爆炸
真正难的是平衡：既要让刷盘跟得上写入节奏，又不能抢光IO带宽影响查询响应。多数人低估了innodb_io_capacity_max和innodb_write_io_threads的联动效应，调一个不调另一个，基本白忙。
