直接修改配置文件并重启MySQL是唯一有效方式，运行时SET无效；需在[mysqld]段设置innodb_read_io_threads=8等值，配合innodb_io_capacity等参数及OS层优化才真正生效。
怎么改 innodb_read_io_threads 才真正生效
直接改配置文件、重启 MySQL，是唯一可靠方式；运行时 SET 是无效的——这个参数属于「只读静态变量」，MySQL 启动后就锁死了，SET GLOBAL innodb_read_io_threads = 8 会报错 Variable 'innodb_read_io_threads' is a read only variable。
- 打开
/etc/my.cnf（Linux）或C:\my.ini（Windows），定位到[mysqld]段落 - 添加或修改这一行：
innodb_read_io_threads = 8（数值建议从 4 起步，别一上来就设 64） - 保存后必须执行
systemctl restart mysqld（或service mysql restart），热加载不支持 - 验证是否生效：连上 MySQL，执行
SELECT @@innodb_read_io_threads;，返回值应与配置一致
设多少合适？不是越多越好，得看硬件和负载类型
innodb_read_io_threads 控制的是 InnoDB 后台做数据页预读、缓冲池刷脏、索引查找等读 I/O 的专用线程数。它对 SSD 有效，对 HDD 效果有限，更关键的是——它只在真正有并发读 I/O 压力时才起作用。
- 默认值是 4，适合单核/双核 + SATA SSD 或普通 HDD 场景
- 现代服务器（16 核以上 + NVMe SSD）可设为 8～12；超过 16 很少带来收益，反而增加上下文切换开销
- 如果是读密集型 OLAP 查询（大表 JOIN、全表扫描多），适当提高该值比调
innodb_write_io_threads更有效 - 若业务以短事务、点查为主（如 API 后端），提升效果可能不明显——瓶颈常在网络或连接池，而非后台读线程
和它配套的几个参数，漏配一个就白调
单独调高 innodb_read_io_threads，但 innodb_io_capacity 还卡在默认 200，等于给跑车配了自行车链条——I/O 调度器压根不放行更多请求。
-
innodb_io_capacity应设为磁盘实测随机读 IOPS 的 50%～75%（例如 NVMe 测出 50k IOPS，这里设 25000～37500） -
innodb_io_capacity_max建议设为innodb_io_capacity的 2 倍，作为突发压力兜底 -
innodb_write_io_threads最好与innodb_read_io_threads对称设置（如都设 8），避免读写线程失衡导致 Redo Log 或 Buffer Pool 刷脏拖慢 - 别忘了
thread_cache_size：如果应用频繁建连断连（比如 PHP-FPM 默认模式），设成 8～16 能显著降低线程创建开销，否则后台 IO 线程再快也救不了前端排队
容易被忽略的陷阱：OS 层面没跟上，配置全打水漂
MySQL 配置再激进，操作系统不配合照样卡死。常见三类硬伤：
- 文件描述符不足：
max_connections = 500时，实际需预留至少 1000+ fd，否则启动就报Can't create thread (errno: 11) - I/O 调度器仍是
cfq（尤其 CentOS 7 默认）：SSD/NVMe 必须切到none（NVMe）或deadline（SATA SSD），否则调度器本身成瓶颈 - NUMA 不均衡：多路 CPU 服务器上，MySQL 进程可能被调度到远端内存节点，
innodb_buffer_pool_size越大，延迟越高；建议用numactl --interleave=all启动 mysqld，或在 BIOS 关 NUMA
线程数调得再细，底层 I/O 被阻塞、内存跨 NUMA 访问、fd 数不够——这些地方一塌方，所有参数优化都只是纸上谈兵。
