MySQL 的 I/O 性能瓶颈通常出在存储层配置，而非 SQL 本身
Linux 下 MySQL 的 I/O 瓶颈很少是磁盘硬件不够快，更多是
innodb_io_capacity、
innodb_flush_method、文件系统挂载选项这些配置没对齐实际硬件能力。SSD 和 NVMe 的随机写行为和 HDD 完全不同，用默认值跑 SSD 反而可能压低吞吐。
关键参数必须按存储类型区分设置
MySQL 的 InnoDB I/O 行为高度依赖底层设备特性，同一套配置在 SATA SSD 和 PCIe 4.0 NVMe 上表现可能差 3 倍以上。
innodb_io_capacity应设为磁盘实测的 70%~80% 随机写 IOPS（例如 fio 测得 50k IOPS，则设
innodb_io_capacity = 40000）
innodb_io_capacity_max一般设为
innodb_io_capacity的 2 倍，避免突发写入被过度限流
innodb_flush_method在 ext4/xfs + SSD 场景下，
O_DIRECT是首选；若使用带电池缓存的 RAID 卡，可尝试
O_DSYNC，但需确认驱动支持 禁用
innodb_doublewrite仅在使用企业级 SSD（如 Intel DCPMM 或带断电保护的 NVMe）且已启用文件系统 barrier 时才考虑，普通云盘或消费级 SSD 必须保留开启
Linux 文件系统与挂载参数直接影响 MySQL 写延迟
ext4 默认挂载参数会引入额外日志刷盘和 barrier 开销，xfs 对大块顺序写更友好，但小事务场景下两者差异不大——关键是关闭不必要的同步行为。
ext4 推荐挂载选项：noatime,nodiratime,barrier=1,commit=60（
barrier=1不可省，否则断电丢数据风险陡增） xfs 推荐挂载选项：
noatime,inode64,logbufs=8,logbsize=256k；若使用
xfs_info查到
mkfs.xfs -f -l size=128m创建的日志，
logbsize应匹配 禁止使用
data=ordered或
data=writeback—— MySQL 自己管理事务日志，文件系统日志模式必须为
data=journal或默认（ext4 默认即 journal 模式） 确保
/var/lib/mysql所在分区未启用
fstab中的
sync选项，该选项会让每次 write() 都等物理落盘
检查与验证 I/O 配置是否生效
光改配置不验证等于没改。很多线上实例明明开了
O_DIRECT，但
iostat -x 1显示 %util 接近 100% 而 await 却很低，说明 I/O 请求被内核合并或排队策略异常，需要交叉验证。 确认 InnoDB 实际使用的 flush 方法：
SELECT @@innodb_flush_method;返回值必须是
O_DIRECT或
O_DSYNC，不是
async_unbuffered（旧版本别名）或空字符串 检查是否真的绕过 page cache：
cat /proc/$(pidof mysqld)/status | grep -i "VmRSS\|VmData"；若
VMRSS显著小于数据文件大小（比如 20G 数据库只占 3G RSS），大概率
O_DIRECT已生效 用
iostat -xmt 1观察
await和
r_await/
w_await：SSD 场景下
w_await > 5ms就值得排查，持续 >10ms 说明写入队列堆积，要检查
innodb_io_capacity是否过低或磁盘饱和 监控
Innodb_buffer_pool_wait_free状态变量：非零值说明 buffer pool clean list 不足，
innodb_io_capacity设置过低或
innodb_lru_scan_depth太小
真正卡住 MySQL I/O 的，往往是
innodb_io_capacity和磁盘实测 IOPS 的数量级错配，或者
innodb_flush_method和文件系统挂载参数互相冲突。调参前务必用
fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=16k --direct=1 --runtime=60 --time_based --group_reporting先测盘，而不是直接套网上的“优化模板”。
