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 然後根據他的值和服務器的性能確定一個最適合當前項目的最大連接數

最大連接數的修改有兩種方式

1. 使用 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;
 

這樣，就能從根本上解決 Too Many Connections 的問題了