一 【現象】

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服務器產生大量物理讀問題優化思路