如何排查MySQL磁盘IO利用率过高-mysql教程-PHP中文网

判断io瓶颈应关注await和avgqu-sz而非%util：await持续>10ms（ssd）或>20ms（hdd）且avgqu-sz>2表明磁盘响应慢；结合iotop、innodb status、刷盘参数及sys schema定位真实原因。

如何排查mysql磁盘io利用率过高

看 iostat 的 %util 和 await 是不是真瓶颈

别一看到 %util 接近 100% 就断定是 MySQL 问题——它在 SSD 或 RAID 上基本没参考价值，尤其云盘或 NVMe 设备。真正该盯的是 await（平均 IO 等待毫秒）和 avgqu-sz（平均队列深度）。如果 await 持续 > 10ms（SSD）或 > 20ms（HDD），且 avgqu-sz > 2，说明磁盘响应变慢，IO 请求在排队。

执行：iostat -xdk 1，重点观察 MySQL 数据目录所在设备（比如 /dev/nvme0n1p1），而不是笼统看 dm-0 或 loop 设备。

若 r/s 和 w/s 高但 rMB/s/wMB/s 很低，可能是小 IO（如随机读页、redo 写），不是吞吐瓶颈而是 IOPS 瓶颈
若 rrqm/s 或 wrqm/s 占比高（>30%），说明内核做了大量 IO 合并，底层设备可能已饱和
iotop -o 必须同步跑，确认 mysqld 进程是否真是 IO 主力，还是被其他进程（如 backup、logrotate）拖累

查 SHOW ENGINE INNODB STATUS 里的 pending IO 和 buffer pool 命中率

Pending normal aio reads/writes 如果长期 > 0（尤其是写），说明 InnoDB 提交的 IO 请求没被系统及时处理；Buffer pool hit rate 若低于 95%，意味着大量物理读——这是最常见原因。

命中率低 ≠ 缓冲池小，也可能是查询扫描范围太大（如全表扫描、大范围 range 查询），导致热数据被挤出
Pages made young 和 not young 比例失衡（前者远小于后者），说明 LRU 链表老化过快，缓冲池实际有效容量打折扣
注意 Modified db pages 数量：若持续很高（比如 > 10 万），且 pending writes 不为 0，说明刷脏压力大，innodb_io_capacity 可能设得太保守

确认 innodb_flush_log_at_trx_commit 和 sync_binlog 是否在从库误配

从库磁盘 IO 高，80% 是因为把主库配置原样搬过去：innodb_flush_log_at_trx_commit=1 + sync_binlog=1，等于每条事务刷两次盘（redo + binlog），完全没必要。

MySQL

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

下载

先查当前值：SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit'; 和 SHOW VARIABLES LIKE 'sync_binlog';，再确认 log_slave_updates 是否开启：

没开 log_slave_updates：从库可安全设 innodb_flush_log_at_trx_commit = 2，sync_binlog = 0
开了 log_slave_updates：保留 sync_binlog = 1 或设为 10，但 innodb_flush_log_at_trx_commit 仍建议用 2
sync_relay_log 默认是 1，从库回放 relay log 时每事务刷一次盘，应改为 10000 减少刷盘频次

用 sys schema 定位高 IO SQL，别只盯着慢查询日志

慢查询日志只记录执行时间长的语句，但很多高 IO 语句执行很快（比如 SELECT COUNT(*) FROM huge_table），却扫了上千万行——这类语句不会进慢日志，但会拉垮 IO。

直接查 sys.statement_analysis 或更精准的 sys.statements_with_full_table_scans：

SELECT digest_text, rows_examined, rows_sent, avg_timer_wait 
FROM sys.statements_with_full_table_scans 
WHERE rows_examined > 100000 
ORDER BY rows_examined DESC LIMIT 5;

关注 rows_examined 而非 exec_count：单次扫描百万行，比一百次各扫千行更伤 IO
digest_text 中带 GROUP BY、ORDER BY、DISTINCT 的语句，容易触发临时表（Created_tmp_disk_tables 计数器飙升），产生额外文件 IO
配合 performance_schema.file_summary_by_event_name 查哪个文件（如 ibdata1、ib_logfile0）被频繁读写，再反推是 undo、redo 还是数据页问题