别设默认值200，也别照搬厂商标称IOPS；必须用fio实测随机写IOPS，再取70%–80%作为innodb_io_capacity值，并同步配innodb_io_capacity_max为1.5–2倍。
直接说结论：别设默认值200，也别照搬厂商标称IOPS；必须用fio实测随机写IOPS，再取70%–80%作为innodb_io_capacity值，并同步配innodb_io_capacity_max为1.5–2倍。
怎么确认当前innodb_io_capacity是不是瓶颈
别猜，看三个关键指标：
-
SHOW VARIABLES LIKE 'innodb_io_capacity';—— 查当前设了多少，如果还是200，SSD基本等于没用上 -
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free';—— 持续非零说明后台刷页跟不上，前台写被卡住 -
SHOW GLOBAL STATUS LIKE 'Innodb_pages_written';—— 算每秒刷页数（比如60秒内从10000涨到16000，就是100页/秒），再换算成IOPS（1页=16KB，4K随机写IOPS ≈ 页数 × 4），对比你磁盘真实能力
fio实测IOPS时该用什么参数
SSD的性能拐点在随机小块写，必须模拟数据库真实负载：
- 命令要带
--ioengine=libaio --direct=1 --bs=4k --rw=randwrite，不能用顺序读或大块写 -
--iodepth=32或64（不是1），否则压不出真实并发能力 - 运行至少60秒：
--runtime=60 --time_based，取最后30秒稳定值，不是峰值 - 结果只看
iops列，不是bw（MB/s）；例如输出iops=92400，就记92400，不是361MB/s
SSD上innodb_io_capacity和配套参数怎么配
设错一个，其他全白调。重点不是“值多大”，而是组合是否闭环：
-
innodb_io_capacity= 实测IOPS × 0.7～0.8（写密集型可到0.9，读多写少降到0.5） -
innodb_io_capacity_max=innodb_io_capacity× 1.5～2（设0会触发InnoDB自动按2倍算，但不可控） -
innodb_flush_neighbors必须为0（SSD上启用邻近页刷新是反效果） -
innodb_write_io_threads建议设4～8（CPU核心数≥8时可设8；设2的话，再高的io_capacity也跑不满） -
innodb_flush_method必须为O_DIRECT（绕过OS cache，否则InnoDB自己调度IO却受系统缓存干扰）
为什么调完还是没改善？常见断点在哪
很多问题根本不在innodb_io_capacity本身：
- Linux I/O调度器没关：
cat /sys/block/nvme0n1/queue/scheduler，NVMe要none，SATA SSD要noop - 文件系统挂载没加
noatime或barrier=0，元数据写入拖慢SSD -
innodb_buffer_pool_size太小，命中率 - 云盘有IOPS配额（如AWS gp3默认3000），实测再高也没用，得查控制台配额
-
innodb_log_file_size太小（比如才48M），导致频繁checkpoint，刷脏页节奏被日志倒逼，不是io_capacity能解决的
真正难的不是算出那个数字，而是把fio、SHOW ENGINE INNODB STATUS、iostat -x 1三组指标串起来看——哪一环卡住，就动哪一环。参数之间没有孤岛，只有链条。
