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 然后根據他的值和服務器的性能確定一個最適合當前項目的最大連接數
最大連接數的修改有兩種方式
- 使用 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;
