innodb_io_capacity不是IO加速器，仅控制后台刷脏页和change buffer合并节奏；设错会导致写入卡顿、锁等待飙升或Buffer Pool命中率暴跌；调后无效主因是未同步启用innodb_adaptive_flushing、未配置innodb_io_capacity_max（应为1.5–2.5倍）、未设innodb_flush_method=O_DIRECT，且须基于fio实测IOPS的60%–80%设定值。
innodb_io_capacity 不是IO加速器，它只控制后台刷脏页和change buffer合并的节奏；设错会导致写入卡顿、锁等待飙升，甚至Buffer Pool命中率暴跌。
为什么调了 innodb_io_capacity 没效果？
常见错误是只改这个参数，却忽略了三个强依赖项：
-
innodb_adaptive_flushing关闭时，innodb_io_capacity几乎不生效 —— 必须执行SET GLOBAL innodb_adaptive_flushing = ON -
innodb_io_capacity_max未配置或设得太低（比如等于innodb_io_capacity），突发脏页压力下无法弹性提速，照样卡住 -
innodb_flush_method不是O_DIRECT（Linux下），OS缓存层会干扰InnoDB对真实I/O能力的判断，导致调度失准
SSD上 innodb_io_capacity 该设多少？
别抄网上“4000”“6000”这种固定值，必须基于你那块盘的真实随机写IOPS：
- 用
fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --direct=1 --iodepth=32 --runtime=60实测，取稳定IOPS的60%～80% - 消费级NVMe SSD实测常在3万～8万IOPS，
innodb_io_capacity建议1000～3000（留余量，避免压满） - 企业级NVMe（如Intel Optane）可设到4000～6000，但需同步调高
innodb_io_capacity_max到其2～2.5倍 - 云盘（如阿里云ESSD）查文档标称IOPS，打6～7折 —— 标称30000就设20000左右
配套必须调的参数有哪些？
单改 innodb_io_capacity 效果有限，以下四项要一起动：
-
innodb_io_capacity_max：设为innodb_io_capacity的2～2.5倍（例如前者4000，后者设10000），应对大事务或主从追平场景 -
innodb_lru_scan_depth：默认1024太小，SSD高并发下易误淘汰热页；建议设为innodb_io_capacity / 4（向下取整到256倍数），如8000→2048 -
innodb_flush_neighbors：SSD上必须设为0，否则邻近页刷新会引入无效I/O，拉长事务锁持有时间 -
innodb_write_io_threads和innodb_read_io_threads：SSD多核并发强，各设4～8（默认4，高配机器可到8）
调完怎么验证是不是真有效？
别只看QPS或TPS，重点盯三个指标：
- 用
SHOW ENGINE INNODB STATUS\G查 “BACKGROUND THREAD” 下的 “pages flushed” 每秒是否平稳，而不是忽高忽低 - 监控
Innodb_buffer_pool_pages_dirty是否长期低于innodb_max_dirty_pages_pct（默认90%），且无持续堆积 - 查
/proc/diskstats：对应设备的await是否 %util 是否
最容易被忽略的是：这个参数只管“写后台”，对SELECT毫无帮助。如果慢查询还在，该加索引加索引，该调buffer pool size调buffer pool size。
