故障案例--尋找瓶頸SQL的一種方法

故障現象

DB響應非常慢,連接數暴漲直到打滿;

任何SQL看起來都是慢查詢,都要幾十秒以上;

show  processlist時SQL種類非常多,短時間無法分辨哪個是引起故障的SQL,挑了幾個看SQL問題不大;

CPU,IO都非常低,看樣子無系統瓶頸,也無任何硬件層面的報錯;

故障原因和定位方法

猜測是高併發引起的性能瓶頸,通過show engine innodb status\G結果看存在大量的sleeping before entering InnoDB,也就是說大量的SQL沒法進入innodb內部執行,存在排隊現象,從而導致這些原本沒問題的SQL也都變成了慢查詢。

一開始懷疑是innodb_thread_concurrency的問題,發現參數設置較爲合理,排除這個原因;

發現show  engine innodb status\G中的事務還能查看當前正在innodb內部執行的SQL,通過搜索關鍵詞inside Innodb即可,數量正好與innodb_thread_concurrency相當,於是確定就是這個SQL引起的,發現這個SQL就是無腦的select * from XX的全表掃描,下線該SQL後問題得到解決


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章