背景

年前本應該是回顧一年工作和收尾的階段，奈何各種促銷，活動都等著春節，因此也遇到了不少的問題，回顧了一下最近遇到的問題，發現有好幾個問題比較類似，正好整理一下，作為年前收尾的案例吧。表現上都是數據庫假死，無響應，發生的場景有較高的業務壓力到來時，也有業務正常運行的時候，突然就出現問題了。

問題描述

由于騰訊云數據庫 MySQL 本身是有故障檢測和高可用機制的，這幾例問題發生的時候，從用戶反饋的問題出現的時間點到實際介入排查的時候已經有好幾分鐘了，但是并沒有觸發高可用切換，說明這個問題可能并不是數據庫自身的故障，也不是一些外部原因導致數據庫不可用。

檢查一下數據庫當時候的狀態，發現一個很不正常的指標：

在問題的時間點附近，連接數的總數量和 threads_running 的數量在短時間內開始飆升，并且接近半分鐘的時間內，連監控插件都采集不到數據了。在相同的時間段內，CPU 的使用率（達到 100%）、慢查詢數量也跟著飆升。基本上可以確認 CPU 使用率，慢查詢，連接數的指標這三者應該是相關聯的，可以從這三者入手來分析這次問題的起因。

原因分析

99%的情況下，只要慢查詢數量在飆升，那么這個問題就和慢查詢脫不了關系，但是案例分析并不能這么草率的下結論。言歸正傳，既然目標縮小在三個指標上，那么分別考慮一下這三個指標的意義，看看這幾個指標的異常會帶來什么問題。

CPU

CPU 過高說明 MySQL 的計算能力被占滿了，能占用 MySQL 計算資源的只有用戶線程和 MySQL 自身的系統線程，這次問題明顯和 MySQL 系統線程沒什么關系，說明用戶線程在大量占用 CPU 的計算資源，而且使用率達到 100% 說明有這個資源爭搶的程度是非常嚴重的，可能會導致原本效率極高的查詢因為拿不到 CPU 資源而變得非常緩慢，從高效率的查詢變成低效的慢查詢，從而產生數據庫假死或者 hang 死的現象。

慢查詢

慢查詢是個老生常談的問題了，因為查詢效率過低，會過度占用 CPU，IO，內存等資源，從而影響到其他正常的查詢，從監控指標上來說，CPU 使用率，IO 使用情況，內存使用率都可能會有不同程度的上升，嚴重的情況下也會引發這幾個指標的飆升，導致整個數據庫響應緩慢。

連接數

連接數通常是一個引發“實際故障”的指標，例如連接數達到 max_connections 的上限，從而導致整個數據庫無法新建連接，程序側直接是報錯的，而不是無響應。threads_running 這個指標，參考官方文檔的描述：

The number of threads that are not sleeping.

簡單直白的解釋，這個指標的飆升代表當時候有大量活躍的用戶連接在 MySQL 實例中。而且從這個案例的監控圖表來看，是一個飆升的趨勢，說明是在短時間內出現了大量的活躍連接。

分析

完成這三個指標的簡單分析，可以發現這個三個指標是互相影響：

1. 慢查詢堆積會導致 CPU 使用率過高；
2. CPU 過高會導致整體的查詢效率變低，進而導致一些高效的查詢變成慢查詢；
3. 慢查詢的執行效率過低，會較長時間的保持活躍狀態，所以 Threads_running 這個指標一定會上漲。
4. 過高的并發突然到來時，大量的查詢處于活躍狀態會讓 Threads_running 這個指標飆升，同時這種尖刺型的高峰也很容易占滿 CPU。
   

看起來三個指標飆升的原因是自洽的，只靠這三個指標并不能真正的判斷出問題的原因。那么仔細考慮一下這幾個指標飆升的原因為什么會自洽？會發現有一個核心現象，或者說是共性：查詢要能夠堆積起來。如果：

1. 堆積起來的查詢本來效率就不高，那么這個問題的誘因基本就是慢查詢了。
2. 堆積起來的查詢效率很高，那么這個問題的誘因可能是瞬間并發過高，或者是其他的原因導致 CPU 使用率暴漲，然后反過來影響了這些效率很高的查詢。
   

所以檢查一下堆積起來的查詢，就能比較直白的分辨出問題了，就上圖展示的這個案例而言，堆積起來的查詢大量使用了 group by 和 order by，查詢的效率比較低，所以根因還是慢查詢。

拓展一下

如開篇所提及，最近發生的問題有多起，且原因類似。除了這個飆升的案例，還有如下所示的現象。

threads_running 保持在一個相對平穩的數值，參考前文的分析，可以發現這個現象代表著在平時的時候，就有約 10 個查詢長時間處于活躍狀態，可以預測一個故障場景：業務量繼續上升，活躍的查詢變多，當高效的查詢受影響，效率降低到一定程度的時候，前端程序/用戶會因為超時或者響應慢的原因，發起重試，然后因為查詢效率降低，這個重試被反復觸發，然后引發雪崩效應，慢慢拖垮數據庫。

萬幸的是多個類似現象的實例僅有一個出現了問題，就是預測的這個場景，其他的都及時優化掉了。

總結一下

雖說仍舊是慢查詢的問題，但是從這個案例可以發現另外一個 MySQL 指標，threads_running 的用處：監控活躍的連接，提前發現一些并發量過高和異常的查詢，防止數據庫堆積查詢，產生假死的現象。

以上就是MySQL Threads_running飆升與慢查詢的問題解決的詳細內容，更多關于MySQL Threads_running飆升與慢查詢的資料請關注腳本之家其它相關文章！