一 【现象】

1、7点到9点IO监控指标util特别高，如下：

2 、查看读写情况：读产生很高的物理IO,如下

【分析】：对比其他服务器，buffer pool都是80G,正常情况下热点数据都是从buffer pool中读取的，产生物理读基本很少，但是这组却产生了很多物理读，肯定是有问题的。

二 【找内鬼】

【基本思路】：既然产生了物理读，下一步我们很容易想到，是哪些表产生了物理io？更具体的就是这些表上哪些SQL会导致物理IO?

1、利用Performance_schema中file_summary_by_instance表统计IO情况。
2、写个脚本，分别统计在7点14到7点20、7点14分到8点14分这两个高峰期间，产生最多物理读的表是哪些。
3、找到表后，查看该表可疑的SQL，重点关注慢查询。

1、 通过统计performance_schema中file_summary_by_instance找到这两个高峰期间产生读物理IO最多的2个表

表已经定位到了，那么再深入一下，找到这些表上哪些SQL可能会导致大量物理读。通过我们开发的sql-trace平台或者通过performance_schema.events_statements_summary_by_digest进行统计。具体语句：

select DIGEST_TEXT,COUNT_STAR,FIRST_SEEN,LAST_SEEN from events_statements_summary_by_digest where DIGEST_TEXT like ‘%`a1`%‘;

2、 a1表上可疑的sql语句

SELECT Max(daydate)as daydate FROM a1 WHERE t_id =2572244 and bid>0;

3、 a2表上可疑的sql语句

SELECT Max(daydate)as daydate FROM a2 WHERE m_id =2572244 and bid>0;

为什么可疑？

可疑1、从时间段上看，以上sql执行时间和产生物理读比较吻合，都是7点到9点。如下：

可疑2、以上两个SQL都是慢查询。
可疑3、通过set profiling跟踪发现产生很多磁盘io，Block_ops_in=22176，Block_ops_out=664。

三 【验明正身】

找到负责的开发同学，发现是通过job跑的，为了确认是不是该SQL语句导致的问题，让开发同学把job延迟一个小时跑
第二天果然发现磁盘IO的高点也延迟了一个小时，到这里基本可以确定“内鬼”了。

【FAQ系列】：DB服务器产生大量物理读问题优化思路