在NVMe SSD环境下如何深度调优MySQL的IO参数配置-mysql教程-PHP中文网

nvme ssd上mysql写入慢主因是innodb_io_capacity设太低且未配innodb_io_capacity_max、innodb_flush_neighbors未关、io调度器未切none；须实测随机写iops（fio -bs=16k -iodepth=64），按0.7～0.8设innodb_io_capacity、1.5～2倍设max，显式关闭innodb_flush_neighbors=0，调度器切none，确认innodb_flush_method=o_direct生效。

在nvme ssd环境下如何深度调优mysql的io参数配置

直接结论：NVMe SSD上MySQL写入慢，九成不是盘不行，而是innodb_io_capacity设得太低，且innodb_io_capacity_max没配、innodb_flush_neighbors没关、IO调度器没切——这四个点漏掉任何一个，调参都白忙。

先实测你的NVMe真实随机写IOPS，别信标称值

消费级NVMe（如SN570）和企业级（如Intel D3700）实际随机写能力差3倍以上，厂商标称“100万IOPS”是4K QD256峰值，MySQL真实负载是16K QD64左右。不实测就调参，等于蒙眼开车。

用fio跑准生产负载：fio --name=randwrite --ioengine=libaio --bs=16k --iodepth=64 --runtime=60 --filename=/var/lib/mysql/ibdata1 --direct=1
重点看输出里的iops字段稳定值（不是第一秒的峰值），取最后30秒平均
如果/proc/diskstats里对应设备的%util == 100%且await > 5ms，说明当前配置已压满磁盘，先别调参，得查是不是被其他进程抢占IO

必须配对设置`innodb_io_capacity`和`innodb_io_capacity_max`

这两个参数是InnoDB刷脏页的“油门”和“红线”，单设一个等于只装半套刹车系统。设太高会触发log file is full等待；设太低则脏页堆积，Pages flushed曲线出现15分钟周期性毛刺（日志切换强制刷盘）。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

innodb_io_capacity = 实测IOPS × 0.7～0.8（留余量），例如实测12万 → 设84000
innodb_io_capacity_max = innodb_io_capacity × 1.5～2，例如84000 → 设126000～168000（不能为0或缺省，否则InnoDB自动按2倍算但不可控）
观察SHOW ENGINE INNODB STATUS\G里的Pages flushed是否平稳；若仍脉冲式上涨，优先加innodb_io_capacity_max，其次检查innodb_write_io_threads是否≥4

关掉`innodb_flush_neighbors`和OS调度器

NVMe没有寻道延迟，预取相邻页不仅无效，还会制造额外IO放大。Linux默认的cfq或deadline调度器在NVMe上反而引入排队延迟，必须切到none。

innodb_flush_neighbors = 0（必须显式关闭，5.7+默认仍是1）
查当前调度器：cat /sys/block/nvme0n1/queue/scheduler（把nvme0n1换成你的真实设备名）
临时生效：echo none > /sys/block/nvme0n1/queue/scheduler
永久生效：改/etc/default/grub，加elevator=none，再update-grub && reboot；云主机需确认宿主机是否已调好

确认`innodb_flush_method=O_DIRECT`真正生效

如果O_DIRECT没起作用，InnoDB以为自己在直接写盘，其实数据还在OS Page Cache里打转，刷盘节奏全乱。这时调innodb_io_capacity再高也没用。

确认配置项是innodb_flush_method = O_DIRECT（Linux下），不是O_DSYNC或空值
查SHOW VARIABLES LIKE 'innodb_flush_method'，输出必须是O_DIRECT
配合文件系统挂载选项：noatime,nobarrier（XFS）或noatime,barrier=0,data=writeback（ext4），否则O_DIRECT会被底层拦截
如果innodb_buffer_pool_size设太大（比如占可用内存90%），导致系统OOM killer干掉mysqld，O_DIRECT也救不了

最容易被忽略的是：所有这些参数必须在my.cnf里持久化，不能只用SET GLOBAL临时改。一次内核升级或服务重启，mysqld-auto.cnf可能被覆盖，所有调优瞬间归零。实测IOPS、配对设capacity、关neighbors、切调度器、验O_DIRECT——五个动作缺一不可，少一个，NVMe的性能就锁死在HDD水平。