故事要從筆者手上的一個項目說起，最近項目有了新的需求，在更新需求的時候，遇到了一個一直以來困擾筆者的狀況，如下如：
由於技術經驗有限，百度了許多關於這方面的案例，基本上都類似於
修改mysql目錄下的my.ini，約在42行下方加入max_connections = 1000 。重啓mysql就行。
Mysql達到連接數上限了，修改一下mysql的配置即可。
show variables like ‘%max_connections%’;
set global max_connections = 5000;
這樣的答案，雖然可以緩解當下情況，但是終究沒有解決本質的問題，而且筆者的情況比較特殊，在該項目中只承擔了部分任務，無法修改my.ini配置及重啓mysql這類修改系統的操作，經過一天的摸索，問題終於得到了解決。
首先，給自己科普了一下關於數據庫的知識，mark！
**長連接：**長連接是相對於短連接來說的。長連接指在一個連接上可以連續發送多個數據包，在連接保持期間，如果沒有數據包發送，需要雙方發鏈路檢測包。mysql的長連接如果長期閒置，mysql會8小時後（默認時間）主動斷開該連接。
**短連接：**是指通訊雙方有數據交互時，就建立一個連接，數據發送完成後，則斷開此連接，即每次連接只完成一項業務的發送。
連接的區別：
使用長連接，短連接各有優勢，也各有缺點。我們看看長短連接，系統是怎麼做的？
1、短連接：
客戶端連接–創建socket認證連接–維護連接–數據傳輸–關閉連接
2、長連接
客戶端連接–創建socket認證連接–維護連接–數據傳輸–維護連接–數據傳輸…-關閉連接
2種連接方式都需要系統開銷來維護連接，哪種連接最合適並沒有準確的說法，主要還是看你客戶端的行爲。
筆者出現too many connection問題是有一個週期性任務，每半分鐘一次，類似於消息隊列，會產生大量睡眠連接佔用mysql資源，導致其無法提供連接而報錯，ThinkPHP5.1默認數據庫連接爲短鏈接，出現大量睡眠連接也是出乎筆者預料。
其次，在自己租的阿里雲服務器進行了一番測試，這是優化前的mysql進程，發現存在大量sleep狀態下的進程：
根據當前需求，嘗試使用長連接：
ThinkPHP5.1設置數據庫長連接
在config目錄下的database.php文件中將parma字段修改爲:
// 數據庫連接參數
'params' => [
\PDO::ATTR_PERSISTENT => true,
\PDO::ATTR_CASE => \PDO::CASE_LOWER,
],
數據庫連接,斷線再連
// 是否需要斷線重連
'break_reconnect' => true,
優化後，效果如下：
經過優化，數據庫可以正常使用。