不能动态修改，必须在my.cnf的[mysqld]段配置并重启生效；默认值为4，nvme+16核可设8～12，需同步调整innodb_io_capacity、write_io_threads等参数。
innodb_read_io_threads 和 innodb_write_io_threads 能不能动态改？
不能。这两个参数只在 MySQL 启动时读取，SET GLOBAL 会报错：Variable 'innodb_read_io_threads' is a read only variable。必须写进 /etc/my.cnf 或 /etc/mysql/my.cnf 的 [mysqld] 段里，改完要重启 MySQL 才生效。
容易踩的坑：
- 误以为加了
SET GLOBAL innodb_read_io_threads = 8就能立刻起效 - 重启前没备份原配置，导致服务起不来
- 在容器环境里改了宿主机的 my.cnf，但容器挂载的是自己的配置文件，实际没生效
设成多少才合适？看 pending I/O 和 CPU 核心数
盲目调高不等于性能更好。关键要看两个指标：
-
SHOW ENGINE INNODB STATUS\G里找Pending normal aio reads/writes—— 如果长期 > 100，说明当前线程数扛不住并发 I/O 请求 -
nproc查 CPU 核心数：线程总数（读+写）一般不超过物理核心数的 2 倍。比如 16 核服务器，innodb_read_io_threads + innodb_write_io_threads ≤ 32
常见组合参考：
- 普通 SATA SSD / 8 核：读 4 + 写 4（默认值，够用）
- NVMe 高并发 OLTP / 16 核：读 8 + 写 8
- 纯分析型大扫描 / 32 核：读 12 + 写 4（写压力小，读吞吐是瓶颈）
为什么不是越多越好？线程争用和上下文切换成本
每个 I/O 线程背后是独立的异步 I/O 请求队列，但底层仍共享磁盘队列、文件描述符、内存锁。设太高反而引发问题：
- Linux 的
aio-max-nr有硬限制（默认 65536），总并发请求数 =(read + write) × 256，超了会静默降级为同步 I/O - 大量线程竞争
buf_pool_mutex或log_sys->mutex，SHOW ENGINE INNODB STATUS里能看到spin waits显著升高 - CPU 花在上下文切换上，
vmstat 1观察cs（context switch）列，持续 > 5000 就值得警惕
搭配 innodb_buffer_pool_instances 使用效果更明显
单个 buffer pool 实例下，所有 I/O 线程都抢同一把锁；开启多实例后，I/O 请求可分散到不同实例，降低锁冲突。两者配合才能释放高线程数的潜力：
- 先确认
innodb_buffer_pool_size≥ 1G，再设innodb_buffer_pool_instances（建议每 1GB 配 1 个，最多 64） - 例如：buffer pool 设为 12G，就配
innodb_buffer_pool_instances = 12，再把innodb_read_io_threads提到 8 - 否则光加 I/O 线程，瓶颈会卡在 buffer pool 锁上，监控里
Buffer pool hit rate可能不升反降
真正卡点往往不在参数数字本身，而在 buffer pool 分片粒度、磁盘队列深度、以及是否触发了内核层的 AIO 降级——这些得靠 iostat -x 1、perf record -e syscalls:sys_enter_io_submit 这类工具交叉验证，光调 my.cnf 不够。
