不能靠调高 innodb_read_io_threads 提升并发读性能——它仅控制后台异步读（如预读、刷脏），不参与用户查询的同步读路径；盲目调高反而加剧锁竞争与内核队列争抢，导致qps下降。
不能靠调高 innodb_read_io_threads 提升并发读性能——它不处理用户查询的主路径 I/O，盲目设高反而引发锁竞争、QPS 下降。
为什么改了 innodb_read_io_threads 却没提速
这个参数只控制后台异步读线程（比如预读、page restore、buffer pool 刷脏时的读取），不参与 SQL 查询执行过程中的数据页加载。用户发起的 SELECT 请求走的是主线程同步读路径，和它无关。
常见错误现象：
- 从 4 改成 12，
Innodb_buffer_pool_read_requests没变，但Threads_running居高不下 -
SHOW ENGINE INNODB STATUS\G中SEMAPHORES区域显示wait array slot使用率 > 80% -
iostat -x 1显示%util未下降，avgqu-sz反而拉高
根本原因不是“I/O 不够”，而是过多 read thread 抢占内核 block queue 和 InnoDB 内部 mutex（如 buf_pool_mutex），导致调度开销上升、锁等待加剧。
什么场景下才值得调这个参数
仅在以下两类后台密集型读负载中可能见效：
- 大表全量扫描（如
mysqldump、SELECT * FROM huge_table） - 物理备份期间（
mysqlbackup或 Percona XtraBackup 的 prepare 阶段）
实操建议：
- NVMe SSD + 16 核以上：可试设
innodb_read_io_threads = 8，必须配合iostat -x 1观察await和%util是否下降 - SATA SSD：保持默认 4 即可，提升有限
- HDD：设超过 4 会加重寻道抖动，反而更慢
- OLTP 点查为主（如 API 后端）：调它毫无意义，瓶颈通常在连接池、网络或
innodb_thread_concurrency
必须同步检查的硬性前提
即使满足上述场景，若以下任一条件不成立，增大 innodb_read_io_threads 也完全无效：
-
SELECT @@innodb_use_native_aio;返回值必须为1；否则退化为模拟 AIO，线程数再多也没用 -
grep -i aio /proc/sys/fs/aio-max-nr输出值 ≥ 所有 I/O 线程总数（如 read+write=16，则需 ≥ 16000） - 文件系统挂载选项不含阻塞项：XFS 用
noatime,nobarrier，ext4 用noatime,data=writeback（仅限有 BBU/UPS 环境） -
innodb_io_capacity必须设为磁盘实测随机读 IOPS 的 50%～75%，否则 I/O 调度器直接限流
真正影响并发读性能的参数在哪
如果你的目标是提升 OLTP 查询吞吐，优先检查并调整：
-
innodb_thread_concurrency = 0：关闭 InnoDB 内部并发限制，交由 OS 调度器管理 -
innodb_buffer_pool_size：命中率低于 95% 时，加内存比加 I/O 线程有效十倍 -
innodb_buffer_pool_instances：缓冲池实例数建议设为 CPU 核数的整数倍（如 16 核设 8），减少buf_pool_mutex争抢 -
max_connections与thread_cache_size：频繁建连断连场景下，thread_cache_size设为 8～16 可显著降低线程创建开销
单独调 innodb_read_io_threads 就像给汽车换涡轮却不改进气和点火——引擎层根本不响应。
