ssd上innodb_io_capacity别设超过2000；应设为1000–2000（中高端取2000，入门级取1000），并成对配置innodb_io_capacity_max为1.5–2倍，同时启用o_direct、trim和innodb_flush_neighbors=0，否则无效。
SSD上innodb_io_capacity别设超过2000
大型数据库跑在SSD上时，innodb_io_capacity设到3000甚至5000是常见误操作——它不加速写入，反而让后台刷脏页节奏失控，引发log file is full、Waiting for query cache lock这类等待。真实瓶颈往往不在参数本身，而在于IO队列是否已饱和：先查/proc/diskstats里对应设备的await是否持续＞10ms、%util是否长期100%，否则调参纯属白忙。
必须和innodb_io_capacity_max成对配置
innodb_io_capacity_max不能缺省或设为0，InnoDB会按innodb_io_capacity的2倍自动算，但线上环境严禁依赖这种不可控行为。
-
innodb_io_capacity设1000–2000：中高端消费级SSD（如致态TiPlus7100）取2000较稳妥；入门级（如金士顿A400）建议1000 -
innodb_io_capacity_max设为1.5–2倍：比如前者2000，后者就设3000–4000；这个值是“弹性上限”，主库突发大事务或从库追延迟时靠它缓冲压力 - 两者都需动态生效：
SET GLOBAL innodb_io_capacity = 2000;+SET GLOBAL innodb_io_capacity_max = 4000;
配套必须检查的三项配置
只调innodb_io_capacity没用，以下三项不匹配，效果直接打折扣：
-
innodb_flush_method必须为O_DIRECT：Linux下若用默认值（或fdatasync），OS缓存层会干扰InnoDB对IO节奏的判断 - SSD必须启用TRIM：运行
lsblk -D确认Disc-GRAN和Disc-MAX非零；没启用就加discard=on到挂载选项并重启MySQL，否则后台刷脏反复写已标记删除的块 -
innodb_flush_neighbors设为0：SSD无寻道成本，邻接页刷盘纯属浪费IO带宽
验证有没有真起效，别只看QPS
重点盯三个地方是否回归平稳：
- 执行
SHOW ENGINE INNODB STATUS\G，关注“BUFFER POOL AND MEMORY”段里的Pages flushed速率是否稳定——突增突降说明节奏失控 - 监控
Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests比值，低于99.5%就要警惕：这不是innodb_io_capacity的问题，是缓冲池太小或索引缺失 - 观察
Innodb_data_fsyncs每秒次数：设太高后该值掉到个位数，说明redo log循环被堵死，IO调度已失衡
复杂点在于：这个参数只管后台脏页刷新和change buffer合并，不管redo log写入——那是innodb_log_file_size和innodb_flush_log_at_trx_commit的事。混淆这两类IO路径，是多数调参失败的根源。
