今天帶著同事一起分析了一個常見的MySQL慢日志報警，從分析的過程希望帶給大家一些啟示和反思。
報警信息類似：
PROBLEM P5 Endpoint:xxxx Metric:mysql.slow_queries Tags:idc=IDC1,port=4306,service=test diff(#1): 335>300 Note:[[warning]SQL語句執行效率慢] Max:3, .....
看到這條報警信息，可以明確一個任務，此時數據庫中存在大量的慢日志，條數為335，超出了閾值設置的300
當然打開日志來分析的時候，會發現比想象的要復雜一些，因為慢日志文件可能有幾百兆甚至更大，要分析整個文件顯然是不可行的，所以我們需要過濾條件，把慢日志限定在一個較小的范圍內來分析。
這里我們可以使用mysqldumpslow來做一個簡單的分析，推薦更好的一款工具是pt-query-digest。
如下是慢日志的頭部：
可以明顯看到在1分鐘的時間里SQL執行的整體情況，1分鐘內有400多的SQL執行。但是仔細看指標“Exec time”會有一個明顯的問題，那就是這個時長指標其實很低，總數才881ms,顯然是不符合我們理解中的慢日志閾值的。
所以我們可以得到一個基本的印象，這個指標是和一個慢日志相關的參數：log_queries_not_using_indexes 相關，這個參數意思是如果SQL沒有使用索引則會計入慢日志。
為了做進一步驗證，我們往下看profile.
看profile信息的時候我們要按照重點來把握，即那些明顯的性能SQL占比通常很高。如果檢查前兩個表會發現，根據現在的條件，這兩條SQL的where條件部分是沒有相關的索引的。
第一個SQL有點意思。
UPDATE SELECT dic_push_dao_assistant tem_selectAssDAO。。。
這是什么意思，我們可以詳細的Query ID的解析來得到。對于update語句會轉義成等價的select語句
update `dic_push_dao_assistant` set `state` = 1 where `id` in ( select `id` from `tem_selectAssDAO` )G # Converted for EXPLAIN # EXPLAIN /*!50100 PARTITIONS*/ select `state` = 1 from `dic_push_dao_assistant` where `id` in ( select `id` from `tem_selectAssDAO` )G
當然這個語句本身是有些粗糙，完全可以進一步優化。
我們再分析一下第2條SQL，問題是很明顯的，即相關的SQL缺少索引而走了全表掃描。
但是建議還是做下補充，可能這些信息是在慢日志之外，就是建表語句：
從這里我們可以清晰的看出，這個表只有2190條記錄，目前的掃描基本就是少數幾個頁就搞定了，但是自增列已經到了1000萬左右，可以看出這個表的變更是極為頻繁的，那么是否存在碎片呢。驗證的方式我們可以直接查看對應的物理文件，可以看到2000條記錄大概占用了20M左右的空間，這能不能說明有碎片呢。
# ll *cccd*
-rw-r----- 1 mysql mysql 70494 Nov 20 09:37 dic_fsm_cccd_info.frm
-rw-r----- 1 mysql mysql 26214400 Feb 27 17:50 dic_fsm_cccd_info.ibd
驗證方式其實也不難，我們在另外一個庫中模擬創建一個表補充數據即可，大概是10M左右。
# ll *cccd*
-rw-r----- 1 mysql mysql 70494 Feb 27 23:47 dic_fsm_cccd_info.frm
-rw-r----- 1 mysql mysql 10485760 Feb 27 23:48 dic_fsm_cccd_info.ibd
所以目前來看這個表是存在碎片的，說明大量的數據是寫入了庫中，然后很可能做了delete操作，導致數據總量變化不大，按照這種方式是存在隱患的。
從自增列來看，很可能數據會出現較大的增長，就會導致這個操作馬上成為瓶頸，這條SQL一分鐘執行了144次，算是比較頻繁了,所以從目前的情況來看，這個表很可能成為性能的瓶頸，所以需要建議業務評估添加相關的索引。而之前根據業務的反饋，說這個庫經常會有一些操作的延遲，也不難理解了。
我們在這里處理應該得出什么結論呢？
1）關閉參數log_queries_not_using_indexes
2）對相關的表進行分析，根據條件和頻率創建相應的索引
其實到了這里，我們的分析還是不夠深入，我們可以發掘出更多的信息，那就是可以提供給業務方一個更全面的信息列表，比如那些表中的索引是冗余索引，那些表走了全表掃描需要考慮添加索引。
這里需要正確引用sys schema,比如：
通過如上的信息可以發現我們需要重點考慮前面的幾個表，走了全表掃描，產生了較大的延遲。
而稍后的解決方法，其實是通過對于業務的反饋優化，在業務添加了相關索引之后，還是建議打開參數：log_queries_not_using_indexes ，這對于一些業務場景的監控其實也是有效的。
如此一來，我們對慢日志的分析也告一段落，如果對于每條報警信息我們都認真對待，其實相應技術能力的提升也會很快。
其實行業里有一個常見的“偽需求“，就是開發同學經常需要關注慢日志，從工作的角色和分工來看，他們得到慢日志之后的分析和處理常常和問題的本質相左，換句話說，他們得到慢日志，是希望通過分析日志來發現一些明顯的性能問題，通過這種信息檢索的方式，來快速定位問題，但是實際上得到日志之后的分析結果是不可控的，可能10分鐘，可能分析不出來。
而這個工作其實是應該作為運維的前置工作來完成的，既然開發對于慢日志的處理不專業，勢必需要DBA來提供專業的建議，而如果我們能夠通過一種透明自助的方式來提供分析和有效建議，對于開發同學來說，其實他們需要的不是慢日志，而是你的數據服務能力。
