innodb_read_io_threads 默认值4已足够，ssd场景无需调高，nvme可试设8但需监控iostat，hdd应保持默认；盲目增加会导致i/o争抢和锁竞争，qps反降。
innodb_read_io_threads 设置多少才合理
MySQL 5.6+ 中 innodb_read_io_threads 默认值是 4，它只控制后台读线程数（如预读、buffer pool 刷脏页的读取），不参与用户查询的主路径 I/O。多核 CPU 下盲目调高这个值，**不会提升 OLTP 查询吞吐**，反而可能因线程争抢磁盘队列或内核锁加剧竞争。
实操建议：
- SSD 场景下，
innodb_read_io_threads=4通常已足够；NVMe 设备且并发读密集（如大表扫描、物理备份期间），可试设为 8，但需配合iostat -x 1观察%util和await是否显著下降 - 机械盘（HDD）场景下，超过 4 反而易引发寻道抖动，保持默认更稳
- 该参数必须和
innodb_write_io_threads平衡设置，二者总和不宜超过 CPU 核心数的 1.5 倍（例如 16 核机器，两者之和 ≤ 24）
为什么调高 innodb_read_io_threads 后 QPS 反而下降
常见错误现象：从 4 改成 16，监控显示 Innodb_buffer_pool_read_ahead 上升，但 Queries 每秒下降，Threads_running 居高不下。
根本原因不是“线程不够”，而是：
- InnoDB 的 read thread 不处理 SQL 请求，只做异步预读和 page restore；真正卡住的是
innodb_thread_concurrency或锁等待（如wait/synch/mutex/innodb/buf_pool_mutex） - 过多 read thread 会抢占
srv_master_thread和srv_worker_thread的调度资源，在高并发下导致 mutex 竞争激增，表现为SHOW ENGINE INNODB STATUS中SEMAPHORES区域 wait array slot 使用率 > 80% - Linux 内核对 block layer 的 queue depth 有限制，线程数远超设备并行能力时，I/O 请求在 kernel queue 中排队，
avgqu-sz拉高，实际吞吐不增反降
比调 innodb_read_io_threads 更有效的多核优化点
真正影响多核利用率的，往往是更底层的并发控制机制，而非 I/O 线程数。
优先检查并调整：
-
innodb_thread_concurrency=0（推荐）：关闭 InnoDB 内部并发限制，让 OS 调度器决定线程运行，避免人为引入排队 -
innodb_read_io_threads和innodb_write_io_threads应保持相等（如都设为 4 或 8），不对称配置易导致 buffer pool 中 page 状态同步延迟 - 确认
innodb_adaptive_hash_index=ON（MySQL 5.7+ 默认 ON）：AHB 能大幅减少二级索引查找的 latch 争用，比加 I/O 线程对锁竞争改善更直接 - 如果使用 MySQL 8.0+，启用
innodb_parallel_read_threads（仅限 SELECT … FROM 表扫描），这才是真正利用多核加速读取的参数，与innodb_read_io_threads完全不同层级
验证改动是否生效的命令和指标
改完 innodb_read_io_threads 后，不能只看“变量是否写入”，要观察真实行为。
关键操作：
- 执行
SELECT * FROM information_schema.INNODB_METRICS WHERE NAME LIKE 'thread%read%';，关注thread_active_read和thread_wait_read的波动幅度——稳定在 3–5 表明线程被有效调度；若长期为 0 或频繁跳变到 16，说明无实际负载或被阻塞 - 运行
mysqladmin debug后查看 error log，搜索 “I/O thread” 字样，确认启动时是否真的拉起了对应数量线程（注意：MySQL 重启后才会重新初始化这些线程） - 对比
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'，重点看Innodb_buffer_pool_read_requests/Innodb_buffer_pool_reads比值——若后者占比升高，说明预读失效，此时加 read thread 是徒劳的，应优先优化索引或查询逻辑
多核 CPU 下的锁竞争，根源往往不在 I/O 线程数量，而在 buffer pool 分区、自适应哈希索引分裂、或者单个热点页（如主键自增页）的 latch 争用。调 innodb_read_io_threads 是最表层的操作，容易掩盖真正瓶颈。
