1. MySQL磁盘IO性能监控的必要性
数据库系统的存储性能直接影响整体响应速度，而磁盘IO往往是MySQL性能的最大瓶颈。当数据库出现查询缓慢、写入延迟等问题时，超过70%的情况都与底层存储IO性能相关。传统的CPU、内存监控无法准确反映这类问题，必须建立专门的磁盘IO监控体系。
我曾在处理一个电商大促期间的数据库卡顿问题时，发现虽然服务器CPU利用率只有60%，但磁盘await（平均等待时间）已经飙升到200ms以上。这就是典型的IO瓶颈案例，只有通过专业的存储性能监控才能快速定位。
2. 核心监控指标解析
2.1 操作系统级指标
这些指标通过Linux工具（如iostat、vmstat）获取，反映物理磁盘的真实负载情况：
await：IO请求的平均等待时间（毫秒）。生产环境建议控制在10ms以内，超过20ms就需要警惕。计算公式：
await = (r_wait + w_wait) / (r_req + w_req)%util：磁盘带宽利用率百分比。持续高于70%说明磁盘过载。
avgqu-sz：平均队列长度。大于1表示请求开始堆积。
svctm：平均服务时间。应与await对比，如果await远大于svctm，说明存在排队问题。
经验：在SSD环境下，await超过5ms就值得关注，传统硬盘可以放宽到15ms
2.2 MySQL特有指标
这些指标需要通过SHOW GLOBAL STATUS获取，反映MySQL内部的IO情况：
| 指标名 | 说明 | 健康阈值 |
|---|---|---|
| Innodb_data_reads | 数据页读取次数 | 需结合缓存命中率分析 |
| Innodb_data_writes | 数据页写入次数 | 监控写入趋势变化 |
| Innodb_log_writes | 重做日志写入次数 | 突然增长可能预示问题 |
| Innodb_os_log_fsyncs | 日志刷盘次数 | 对比写入量分析 |
| Created_tmp_disk_tables | 磁盘临时表创建数 | 应尽量低于内存临时表 |
3. 监控方案实施
3.1 基础工具组合方案
方案一：iostat + vmstat + MySQL自带监控
# 每2秒采集一次，共10次 iostat -xmt 2 10 | tee /tmp/iostat.log vmstat 2 10 | tee /tmp/vmstat.log同时开启MySQL监控：
-- 每5秒记录一次状态变量差值 SHOW GLOBAL STATUS WHERE Variable_name LIKE 'Innodb%io%';方案二：Percona PMM（Percona Monitoring and Management）
安装步骤：
- 下载Docker镜像：
docker pull percona/pmm-server:2 - 启动服务：
docker run -d -p 80:80 -p 443:443 \ --name pmm-server \ -v /srv/pmm-data:/srv/pmm-data \ percona/pmm-server:2 - 客户端安装：
curl -fsSL https://raw.githubusercontent.com/percona/pmm-client/main/install.sh | bash pmm-admin config --server-url=https://<服务器IP> --server-insecure-tls pmm-admin add mysql --username=pmm --password=密码 --query-source=perfschema
3.2 关键配置调优建议
在监控过程中发现IO问题时，可考虑以下调优措施：
InnoDB缓冲池优化：
innodb_buffer_pool_size = 总内存的70-80% innodb_buffer_pool_instances = 8 # 多实例减少争用日志文件配置：
innodb_log_file_size = 4G # 大日志减少checkpoint innodb_flush_log_at_trx_commit = 2 # 非关键业务可放宽IO调度器选择：
# 对SSD推荐使用none或deadline echo deadline > /sys/block/sda/queue/scheduler
4. 高级监控技巧
4.1 慢查询与IO关联分析
通过performance_schema实现查询级IO监控：
-- 启用等待事件收集 UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_waits%'; -- 查询文件IO等待最多的SQL SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT/1000000000 AS wait_sec FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE '%file%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;4.2 压力测试基准建立
使用sysbench建立IO性能基线：
# 准备测试数据 sysbench --db-driver=mysql --mysql-user=test \ --mysql-password=test --mysql-db=sbtest \ --tables=10 --table-size=1000000 oltp_read_write prepare # 运行测试 sysbench --db-driver=mysql --mysql-user=test \ --mysql-password=test --mysql-db=sbtest \ --tables=10 --table-size=1000000 --threads=32 \ --time=300 --report-interval=10 oltp_read_write run测试时应同步监控iostat，记录正常负载下的指标值作为基准。
5. 常见问题排查指南
5.1 突发IO飙升处理流程
确认现象：
- 通过
iostat -xmt 1观察实时IO - 检查MySQL状态：
SHOW PROCESSLIST
- 通过
定位源头：
-- 查看当前活跃事务 SELECT * FROM information_schema.INNODB_TRX; -- 检查锁等待 SELECT * FROM sys.innodb_lock_waits;典型原因：
- 大表全表扫描
- 未提交的长事务
- 突然的批量导入
- 备份任务冲突
5.2 监控数据持久化方案
推荐使用以下组合实现历史数据分析：
Telegraf：数据采集
[[inputs.mysql]] servers = ["tcp(127.0.0.1:3306)/"] perf_events_statements_digest_text_limit = 120InfluxDB：时间序列存储
# 启动容器 docker run -d -p 8086:8086 \ -v influxdb:/var/lib/influxdb \ influxdb:1.8Grafana：可视化展示
docker run -d -p 3000:3000 \ -v grafana:/var/lib/grafana \ grafana/grafana
6. 生产环境经验总结
在实际运维中，我发现几个容易忽视但至关重要的点：
监控频率：生产环境建议至少1分钟粒度，关键业务需要秒级监控。但要注意监控工具本身不要带来额外IO负担。
指标关联：单独看磁盘await可能误判，需要结合%util、队列长度等指标综合分析。我曾经遇到await高但%util低的情况，最终发现是RAID卡电池故障导致写入降速。
SSD特殊考量：现代SSD的写入放大问题需要特别关注。可以通过监控
innodb_redo_log_flushed_to_disk_lsn的变化速率来评估真实写入量。云环境差异：云数据库的IOPS通常有配额限制，监控时要额外关注突发性能的持续时间。AWS RDS的Enhanced Monitoring功能就非常有用。
最后分享一个诊断脚本，可以快速生成IO性能报告：
#!/bin/bash echo "===== Disk IO Top =====" iostat -xmt 1 5 | awk '/^[sd]/{print $1,$10,$11,$12}' echo -e "\n===== MySQL IO Status =====" mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb%io%'" echo -e "\n===== Top 5 IO Wait Threads =====" mysql -e "SELECT thread_id,event_name,timer_wait/1000000000 FROM performance_schema.events_waits_current WHERE event_name LIKE '%file%' ORDER BY timer_wait DESC LIMIT 5"
