觀察到 MySQL 停頓和奇怪的執行緒/連接行為
我們有一個 MySQL 實例，大部分時間都可以正常工作。然而，我們有時會觀察到奇怪的行為。發生的情況是 MySQL 連接突然達到限制（目前設置為 1000）並且 MySQL 幾乎停滯不前。當我們檢查此伺服器的圖表時，會觀察到以下情況：
該圖像來自執行 MySQL 導出器的 Grafana 實例。困擾我的是為什麼記憶體中的執行緒沒有被重用。另一個問題是為什麼記憶體中的執行緒突然下降到零，但同時沒有創建新執行緒（根據第二張圖 - 藍線保持在 0）。
最終，我的目標是了解為什麼突然使用 1000 個連接，以及這是否是 MySQL 或應用程序的問題。這是 MySQL 文件關於執行緒的說法：
伺服器應記憶體多少執行緒以供重用。當客戶端斷開連接時，如果客戶端的執行緒少於 thread_cache_size 執行緒，則將客戶端的執行緒放入記憶體中。如果可能，通過重用從記憶體中獲取的執行緒來滿足對執行緒的請求，並且只有當記憶體為空時才會創建新執行緒。
任何幫助或指導將不勝感激！
雷霆萬鈞。或者，雜貨店裡的人太多，以至於沒有人可以移動他們的購物車。
什麼時候
Threads_running是 349，他們每個人都在等待，等待，等待一小部分 CPU 和少量 I/O 和……結果是他們都需要“永遠”才能完成。同時，其他試圖進入的人*被允許進入，*因為你有這麼高max_connections的等。但是，這並不能解釋是什麼將牛群推下懸崖。這可能是一件微不足道的事情
SELECT，恰好阻止了牛群通常做的事情。你有打開慢日誌嗎？低值
long_query_time? 如果是這樣，您可能已經在慢日誌中找到了答案。由於您沒有驚慌並重新啟動，因此慢速 Select（如果確實存在）將在慢速日誌中。根據圖表，我猜它可能需要 80-110 秒的時間。至於下降
Threads_cached，這有點複雜。首先，讓我解釋一下非浸入部分。在“事件”之前，建立了大約 200 個連接；每個都持續了足夠長的時間，以便有一個“穩定”的 200 個連接。活動結束後，等待入場的人數眾多，將人數推高至約350人。
有
thread_cache_size = 500浪費記憶；建議你把它降低到250。至於跌幅，我會做一些猜測。如此多的連接都在努力完成任務，以至於新連接被拒絕訪問。（這可能是 MySQL 故意的，也可能是每個人都在爭奪各種互斥鎖的副作用。）
擁有也不明智
max_connections = 1000；這只是邀請這樣的場景。取而代之的是，當出現問題時，讓客戶“承擔責任”——通過拒絕訪問 MySQL。此外，這更容易說“糟糕，遇到問題，請稍候，請不要再次按發送，也不要刷新！” 或者乾脆給出“500”。底線：我認為慢日誌可以指出事件的原因。