SSD上需调高innodb_read_io_threads至8–12、innodb_write_io_threads至4–8，因默认值4仅适配HDD，无法发挥SSD/NVMe高并行IOPS能力；必须验证innodb_use_native_aio=1、aio-max-nr充足及挂载选项无barrier，否则线程无效。
SSD上直接设 innodb_read_io_threads=8、innodb_write_io_threads=6 就能明显改善I/O吞吐，但必须同步验证 innodb_use_native_aio 是否真生效，否则线程数再高也白搭。
为什么SSD要调高I/O线程数而不是照搬默认值
MySQL 8.0默认都是4，这对HDD勉强够用，但SSD（尤其是NVMe）的并行能力远超机械盘——单盘就能支撑10万+ IOPS，而4个线程根本喂不饱。线程太少会导致I/O请求排队，SHOW ENGINE INNODB STATUS\G 中的 pending normal aio reads/writes 持续非零就是典型信号。SSD没有寻道延迟，真正瓶颈在系统层AIO调度和内核支持，不是磁盘本身。
常见错误现象：[ERROR] InnoDB: Error: io_setup() failed with EAGAIN after 5 attempts —— 这说明内核AIO资源不足，不是参数设小了，而是底层没准备好。
- 读多写少（如OLTP查询密集型）：优先加
innodb_read_io_threads，比如设为8–12，innodb_write_io_threads保持4–6 - 写多读少（如日志归档、批量导入）：可设
innodb_read_io_threads=6、innodb_write_io_threads=8 - 混合负载且读写比接近1:1：设为8/6或8/8更稳妥，避免某类I/O长期积压
必须验证 native AIO 是否真正启用
MySQL 8.0虽默认 innodb_use_native_aio=1，但Linux内核若未正确配置，会悄悄退化为模拟AIO（emulated AIO），此时增大线程数毫无意义，甚至增加CPU上下文切换开销。
执行 SELECT @@innodb_use_native_aio;，结果必须是 1；再检查内核AIO容量：grep -i aio /proc/sys/fs/aio-max-nr，输出值应 ≥ 所有I/O线程总数 × 1000（例如 read+write=14，则需 ≥14000）。
容易踩的坑：/etc/fstab 中挂载选项含 barrier=1 或 data=ordered（ext4）会阻塞原生AIO；XFS需确认挂载参数含 noatime,nobarrier，否则AIO被降级。
配合调整 innodb_io_capacity 和缓冲池
I/O线程只是“搬运工”，真正决定搬运效率的是“货物量”和“道路宽度”。如果 innodb_buffer_pool_size 太小，命中率低于95%，大量请求仍要走物理读，线程再多也得干等磁盘响应。
innodb_io_capacity 必须匹配SSD实测性能：SATA SSD建议2000–4000，NVMe可设5000–10000；该值设太低会限制后台刷新节奏，设太高则可能压垮设备——观察 iostat -x 1 中的 %util 是否长期≈100%、avgqu-sz 是否持续＞2，是关键判断依据。
另外，innodb_flush_neighbors=0 必须开启（SSD无顺序写优势），innodb_flush_method=O_DIRECT 避免双重缓冲，这两项不配，I/O线程优化效果打五折。
上线后盯紧这几个指标才敢说调优有效
改完配置重启后，不能只看QPS涨没涨。真正反映I/O线程是否起效的，是InnoDB内部队列水位和系统级I/O分布：
- 每5分钟查一次：
SHOW ENGINE INNODB STATUS\G，重点关注PENDING NORMAL AIO READS和WRITES行，理想状态是多数时间显示0，偶发≤2 - 用
perf top -p $(pgrep mysqld)看io_submit、io_getevents占比是否上升，说明AIO调用变活跃 -
pt-ioprofile抓10秒磁盘栈，确认mysqld进程调用的是io_submit而非pwrite64—— 后者代表还在用同步I/O
最常被忽略的一点：线程数调高后，mysqld 进程的CPU user%会上升，这是正常现象；但如果 sys% 也同步飙升，大概率是内核AIO未就绪或文件系统挂载参数冲突，得回头重检 aio-max-nr 和挂载选项。
