首先检查系统级磁盘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 或内部机制导致，最后调整配置或优化结构。整个过程不复杂但容易忽略关联性。