排查MySQL磁盘IO瓶颈需先定位高IO操作，通过开启慢查询日志并分析执行次数多或扫描行数大的语句，重点关注全表扫描和未使用索引的查询；接着检查InnoDB缓冲池命中率，若低于95%表明物理读频繁；监控Created_tmp_disk_tables判断临时表写磁盘情况；使用iostat和iotop分析系统IO负载，确认%util、await等指标是否异常；最后优化日志策略，调整innodb_flush_log_at_trx_commit、增大redo log大小，并将日志文件分布到高速磁盘以降低IO压力。
排查 MySQL 中的磁盘 IO 瓶颈，关键在于识别哪些操作导致了大量读写，并分析系统与数据库层面的响应表现。重点看慢查询、临时表使用、日志写入以及系统 IO 负载情况。
检查慢查询日志
开启并分析慢查询日志是定位高 IO 操作的第一步。长时间运行的查询通常伴随大量数据扫描，增加磁盘读取压力。
- 确保慢查询日志已启用：SET GLOBAL slow_query_log = 'ON';
- 设置阈值，例如超过1秒的查询记录：SET GLOBAL long_query_time = 1;
- 使用 mysqldumpslow 或 pt-query-digest 分析日志，找出执行次数多或扫描行数大的语句
- 重点关注全表扫描（type=ALL）和未使用索引的查询
监控 InnoDB 存储引擎状态
InnoDB 的内部状态能反映缓冲池效率和物理读写频率，帮助判断是否频繁访问磁盘。
- 执行 SHOW ENGINE INNODB STATUS\G，查看“BUFFER POOL AND MEMORY”部分
- 关注 Pages read/written 数量，若每秒读取页数过高，说明缓冲池命中率低
- 计算缓冲池命中率：(1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)) * 100%，低于95%需警惕
- 检查是否有大量临时表写入磁盘：查看 Created_tmp_disk_tables 值是否持续增长
分析操作系统级 IO 使用情况
数据库性能受限时，系统层面的 IO 饱和往往是根本原因。
- 使用 iostat -x 1 查看磁盘使用率，重点关注 %util 是否接近100%
- 观察 await（平均等待时间），若显著高于服务时间（svctm），说明存在队列堆积
- 结合 iotop 查看 mysqld 进程的实际读写速率
- 确认数据文件、binlog、redo log 是否分布在不同物理磁盘，避免争抢
优化日志和刷写策略
MySQL 的日志机制可能成为 IO 瓶颈源头，尤其是高并发写入场景。
- 调整 innodb_flush_log_at_trx_commit：设为2可减少磁盘同步频率（牺牲部分持久性）
- 增大 innodb_log_file_size 和 innodb_log_files_in_group，减少 checkpoint 频率
- 考虑将 redo log 和 binlog 放置在高速存储设备上
- 避免频繁的 sync_binlog，生产环境可设为0或100
基本上就这些。从查询到配置层层排查，多数磁盘 IO 问题都能定位清楚。关键是建立监控基线，对比异常时段的变化。
