InnoDB I/O线程数需按硬件（NVMe设8–12、SATA SSD设6–8、HDD≤4）和负载（OLTP读多则读线程高2–4）设定，并配合innodb_io_capacity（设为磁盘IOPS的50%–75%）协同优化，同时验证innodb_use_native_aio=1及磁盘未饱和。
innodb_read_io_threads 和 innodb_write_io_threads 设多少才不浪费也不卡顿
这两个参数控制 InnoDB 后台异步 I/O 线程数，默认都是 4（MySQL 8.0+），但“默认值”在高并发、NVMe 或多盘环境里大概率不是最优解。设小了，I/O 成瓶颈，SHOW ENGINE INNODB STATUS 里常看到 pending normal aio reads/writes 持续不为 0；设大了，线程争抢反而拖慢响应，尤其在 CPU 核心少或磁盘吞吐已饱和时。
实操建议：
- 先看硬件：单 NVMe 盘可设到 8–12；SATA SSD 建议 6–8；传统 HDD 别超过 4，再多线程也喂不饱磁盘
- 再看负载特征：纯 OLTP 场景读多写少，
innodb_read_io_threads可比innodb_write_io_threads高 2–4；批量导入或日志刷盘重的场景则反过来 - 必须搭配监控验证：改完重启后，持续观察
innodb_buffer_pool_wait_free和innodb_data_pending_reads/writes是否回落，同时用iostat -x 1看%util和await是否同步改善
为什么调了线程数，iostat 却看不出变化
常见错误现象是改完 innodb_read_io_threads=12，重启后 iostat 的 IOPS 或吞吐没涨，甚至 await 更高了——这说明线程数不是瓶颈，真正卡在别处。
原因和排查点：
- 缓冲池太小：
innodb_buffer_pool_size不足导致频繁物理读，加线程只是让排队更长，优先检查innodb_buffer_pool_reads / innodb_buffer_pool_read_requests比值是否 > 1% - 磁盘本身打满：
iostat -x中%util ≈ 100且avgqu-sz持续 > 2，说明磁盘已达极限，加线程无意义 - 文件系统或挂载选项限制：比如 XFS 没开
noatime,logbufs=8，或 ext4 的 journal 模式拖慢写入，此时调 I/O 线程只是隔靴搔痒
MySQL 5.7 和 8.0 在这两个参数上的关键差异
MySQL 8.0 把异步 I/O 能力从 Linux AIO 扩展到 Windows 和部分其他平台，但更重要的是：8.0 默认启用 innodb_use_native_aio = ON，而 5.7 在某些内核版本下会自动退化为模拟 AIO（即 sync mode），这时增大 innodb_read_io_threads 几乎无效。
验证和适配要点：
- 运行
SELECT @@innodb_use_native_aio;，结果必须为 1 才算真正走原生 AIO；否则即使线程数设得再高，实际仍是单线程轮询 - Linux 下确认内核支持：
grep -i aio /proc/sys/fs/aio-max-nr应远大于你设的线程总数（比如设 12 读 + 12 写，至少留 512 的余量） - 5.7 用户若发现
innodb_use_native_aio为 0，需升级内核或换发行版（如 CentOS 7.6+ / Ubuntu 18.04+），不能只调参数
容易被忽略的配套参数：innodb_io_capacity 和 innodb_io_capacity_max
很多人调了 I/O 线程就以为完事，但 innodb_io_capacity 才决定每秒刷脏页、合并插入缓冲等后台任务的节奏。如果它卡在默认 200，而你的 NVMe 实际能跑 50k IOPS，InnoDB 就会人为压低刷新速度，导致 dirty pages 积压、Checkpoint 延迟、最终触发陡峭的刷盘风暴。
正确做法：
-
innodb_io_capacity设为磁盘随机读写 IOPS 的 50%～75%（例如 NVMe 实测 40k IOPS，则设 20000–30000） -
innodb_io_capacity_max设为innodb_io_capacity的 2 倍，给突发负载留缓冲，避免因瞬时压力触发强制刷盘 - 注意：这两个值不影响前台查询线程，但直接影响后台 I/O 调度强度，和
innodb_read_io_threads协同工作——线程是“人手”，capacity 是“每人每秒干多少活”
线程数调得再高，capacity 卡得太死，I/O 依然跑不满；capacity 放得太开，线程数不够，任务还是堆在队列里。两者得一起看，不能只盯一个。
