共計 1207 個字符,預計需要花費 4 分鐘才能閱讀完成。
自動寫代碼機器人,免費開通
MySQL 連接數太多如何解決,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
MySQL 數據庫的默認最大連接數是:100,
對于多人開發的單體項目來說,雖然我們同時在用的連接不會超過 10 個,理論上 100 綽綽有余,但是除了我們正在使用的連接以外,還有很大一部分 Sleep 的連接,這個才是真正的罪魁禍首。
分析到了問題的根源,我們就需要對癥下藥,依次解決:
修改 MySQL 最大連接數量
首先查看當前 Mysql 最大連接數量是多少:
show variables like %max_connections%
這里我已經修改過了,所以是 1000,沒有改過的童鞋應該還是 100,
然后查看從這次 mysql 服務啟動到現在,同一時刻并行連接數的最大值:
show status like Max_used_connections
對于 MySQL 的最大連接數設置,在首次配置的時候設置一個較大的數值,以后在使用的過程中,周期的查詢 Max_used_connections 然后根據他的值和服務器的性能確定一個最適合當前項目的最大連接數
最大連接數的修改有兩種方式
鴻蒙官方戰略合作共建——HarmonyOS 技術社區
使用 sql 語句 (立即生效,但服務器重啟后失效):
set global max_connections = 1000;
1 修改 /etc/my.cnf. 添加 max_connections = 1000 永久有效。重啟后生效
但更改最大連接數只能從表面上解決問題,隨著我們開發人員的增多,Sleep 連接也會更多,到時候萬一又達到了 1000 的上限,難道我們又得改成 10000 嗎?這顯然是非常不可取的。所以我們不僅要治標,還要治本。殺掉多余的 Sleep 連接就是治本
殺掉 Sleep 連接
我們可以通過 show_processlist 命令來查看當前的所有連接狀態
可以發現,Sleep 的連接占了絕大多數。
MySQL 數據庫有一個屬性 wait_timeout 就是 sleep 連接最大存活時間,默認是 28800 s,換算成小時就是 8 小時,我的天吶!這也太長了!嚴重影響性能。相當于今天上班以來所有建立過而未關閉的連接都不會被清理。
執行命令:
show global variables like %wait_timeout
我們將他修改成一個合適的值,這里我改成了 250s。當然也可以在配置文件中修改,添加 wait_timeout = 250。這個值可以根據項目的需要進行修改,以 s 為單位。我在這里結合 navicat 的超時請求機制配置了 240s。
執行命令:
set global wait_timeout=250;
關于 MySQL 連接數太多如何解決問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注丸趣 TV 行業資訊頻道了解更多相關知識。
向 AI 問一下細節