MySQL數(shù)據(jù)庫的默認(rèn)最大連接數(shù)是：100，
對于多人開發(fā)的單體項(xiàng)目來說，雖然我們同時(shí)在用的連接不會超過10個(gè)，理論上100 綽綽有余，但是除了我們正在使用的連接以外，還有很大一部分 Sleep 的連接，這個(gè)才是真正的罪魁禍?zhǔn)住?/p>
分析到了問題的根源，我們就需要對癥下藥，依次解決：
修改MySQL最大連接數(shù)量
首先查看當(dāng)前 Mysql 最大連接數(shù)量是多少：
- show variables like '%max_connections%';
這里我已經(jīng)修改過了，所以是 1000，沒有改過的童鞋應(yīng)該還是 100，
然后查看從這次 mysql 服務(wù)啟動到現(xiàn)在，同一時(shí)刻并行連接數(shù)的最大值：
- show status like 'Max_used_connections';
對于 MySQL 的最大連接數(shù)設(shè)置，在首次配置的時(shí)候設(shè)置一個(gè)較大的數(shù)值，以后在使用的過程中，周期的查詢 Max_used_connections 然后根據(jù)他的值和服務(wù)器的性能確定一個(gè)最適合當(dāng)前項(xiàng)目的最大連接數(shù)
最大連接數(shù)的修改有兩種方式
- 使用 sql 語句(立即生效，但服務(wù)器重啟后失效)：
- set global max_connections = 1000;
1修改 /etc/my.cnf.添加 max_connections = 1000 永久有效。重啟后生效
但更改最大連接數(shù)只能從表面上解決問題，隨著我們開發(fā)人員的增多，Sleep 連接也會更多，到時(shí)候萬一又達(dá)到了 1000 的上限，難道我們又得改成 10000 嗎？這顯然是非常不可取的。所以我們不僅要治標(biāo)，還要治本。殺掉多余的 Sleep 連接就是治本
殺掉Sleep連接
我們可以通過 show_processlist 命令來查看當(dāng)前的所有連接狀態(tài)
可以發(fā)現(xiàn)， Sleep 的連接占了絕大多數(shù)。
MySQL 數(shù)據(jù)庫有一個(gè)屬性 wait_timeout 就是 sleep 連接最大存活時(shí)間，默認(rèn)是 28800 s，換算成小時(shí)就是 8 小時(shí)，我的天吶！這也太長了！嚴(yán)重影響性能。相當(dāng)于今天上班以來所有建立過而未關(guān)閉的連接都不會被清理。
執(zhí)行命令：
- show global variables like '%wait_timeout';
我們將他修改成一個(gè)合適的值，這里我改成了 250s。當(dāng)然也可以在配置文件中修改，添加 wait_timeout = 250。這個(gè)值可以根據(jù)項(xiàng)目的需要進(jìn)行修改，以 s 為單位。我在這里結(jié)合 navicat 的超時(shí)請求機(jī)制配置了 240s。
執(zhí)行命令：
- set global wait_timeout=250;
