排查 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 问题都能定位清楚。关键是建立监控基线，对比异常时段的变化。
