前言
-
平時在工作中每天都會做巡檢，將前一天所有超過500ms的慢SQL排查出來
-
查詢原因，是否能進行優化。慢慢中，在形成了一套思路方法論。
- 我個人認為對於排查慢SQL還是有一定的幫助
（一）、是否是SQL語句本身導致的慢SQL
- SQL語句是否走了索引。此條可以用explain命令檢視
- SQL語句是不是select的資料量非常非常的大。比如是一個長長的json串，在網路傳輸的過程中會非常的耗時
（二）、SQL慢查詢是否是其他外在因素導致的
-
如果SQL語句本身沒有問題，大概率就是偶爾出現，其他因素影響的。
-
慢SQL這段時間，請求量是否很大，MySQL是否能支撐住此刻的訪問量
- 此刻時間，是否有定時任務在大量運算元據庫，造成鎖表等？
-
是不是其他組執行了一條很長的操作，影響了你們的SQL
（三）、SQL慢查詢是否只在一個機房出現
-
比如應用部署在了A, B兩個機房。當時資料庫在A機房。
-
此時A機房的應用請求資料庫，明顯會比B機房的應用，跨機房請求A機房的資料庫要效果好。
- 此刻時間，是否只有跨機房才會出現慢SQL。同機房不會出現
（四）、SQL慢查詢是否由於網路原因
-
比如應用到資料庫並不是直連的，。應用 --> 中介軟體A --> 中介軟體B --> 資料庫例項
-
應用到中介軟體A。此段網路是否正常，中介軟體A 到B是否正常，中介軟體B到資料資料庫是否正常等等
- 可以用tcpdump抓包看看。是否出現了重傳的現象，是否某一刻網路出現了問題等等