首先检查系统级磁盘IO，使用iostat、iotop等工具分析磁盘利用率和进程IO行为；再通过MySQL慢查询日志、sys.schema视图及SHOW ENGINE INNODB STATUS排查高IO消耗的SQL与内部等待事件；接着评估innodb_buffer_pool_size、innodb_io_capacity等参数配置合理性；最后结合缓冲池命中率、pending IO请求、读写延迟等指标判断瓶颈类型，确定是否因配置不当或硬件限制导致IO压力过高。
排查 MySQL 磁盘 IO 瓶颈需要从系统层和数据库层两个维度入手，重点观察读写延迟、吞吐量以及等待事件。以下是具体的排查思路和操作方法。
1. 检查系统级磁盘 IO 使用情况
使用系统工具查看磁盘是否达到性能极限：
-
iostat：监控磁盘读写速率和响应时间
执行：iostat -x 1 5
关注指标：
- %util：接近 100% 表示磁盘繁忙
- await / svctm：IO 平均等待时间，过高说明存在瓶颈
- r/s 和 w/s：每秒读写次数，结合业务判断是否异常 -
iotop：查看哪些进程在大量读写磁盘
执行：iotop -o 可筛选出正在做 IO 的进程，确认是否为 mysqld 主导 - df 和 iotop 配合：确认 MySQL 数据目录所在磁盘是否空间不足或负载高
2. 分析 MySQL 内部的 IO 相关状态
通过 MySQL 自身的性能视图定位高 IO 操作来源：
-
查看慢查询日志
开启并分析慢查询：slow_query_log=ON
设置阈值（如 long_query_time=1），找出执行时间长、扫描行数多的 SQL -
使用 performance_schema 或 sys schema
查询消耗 IO 多的语句：
SELECT * FROM sys.statements_with_full_table_scans ORDER BY rows_examined DESC LIMIT 5;
查看是否有大量全表扫描导致随机读增加 -
检查 InnoDB 状态
执行：SHOW ENGINE INNODB STATUS\G
关注以下部分：
- BUFFER POOL AND MEMORY：缓冲池命中率（应 > 95%）
- FILE I/O：当前 pending 的读写请求数，若持续不为 0 说明 IO 跟不上
- INSERT BUFFER AND ADAPTIVE HASH INDEX：AHI 是否失效导致更多页读
3. 判断是否因配置不合理引发 IO 压力
某些参数设置不当会显著增加磁盘 IO：
-
innodb_buffer_pool_size 过小
导致频繁从磁盘加载数据页。建议设置为物理内存的 60%~80%（专用数据库服务器） -
innodb_io_capacity 和 innodb_io_capacity_max
应根据磁盘类型调整（SSD 可设为 2000/4000，HDD 设为 200/400），影响后台刷脏速度 -
双写机制与日志策略
- innodb_doublewrite=ON 是安全保障，但会增加写放大
- innodb_flush_log_at_trx_commit=1 最安全，但每次提交都刷日志，可考虑业务容忍度调整
4. 观察关键指标组合判断瓶颈类型
结合多个指标快速定位问题性质：
- 如果 buffer pool hit rate
- pending io 请求多 + %util 接近 100% → 磁盘处理不过来
- 大量全表扫描 SQL 出现 → 应优化查询或添加索引
- 写密集场景下 checkpoint age 太长 → redo 日志循环压力大，触发大量脏页刷新
基本上就这些。关键是把系统工具和 MySQL 内部状态结合起来看，不能只盯一个点。发现 IO 高之后，先确认是不是数据库引起的，再查是哪些 SQL 或内部机制导致，最后调整配置或优化结构。整个过程不复杂但容易忽略关联性。
