Navicat使用常見問題
在我們日常開發過程中，一般不會直接使用命令行來操作 MYSQL 數據庫，而會選擇一些圖形化界面去幫助我們來進行此類操作，常用的有：SQLyog(Logo也是小海豚),Navicat,或者直接使用編輯器自帶的圖形化界面工具。我這邊開發使用的是 Navicat，在日常使用的時候出現過一下的問題：
Too Many Connections - 1040
在 Navicat 的界面中，這是一個很討人厭的提示框，多人協作開發的時候經常出現。原因有二：
一是 Mysql 數據庫的默認最大連接數是：151，
二是 對於多人開發的單體項目來說，雖然我們同時在用的連接不會超過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;
- 修改 /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 的問題了
正在准備...
我們在使用 Navicat 的時候，有時候查詢完一次數據之后，就去編寫代碼，等下次回來的打開表的時候就會出現：正在准備... 等字樣，這次查詢可能會消耗 20s 以上的時間，這是不能容忍的。
這個時候我們就需要想辦法解決他了，首先我想到的是 mysql 的 connection 連接被清理了，通過復現 正在准備... 並同時在 linux 通過 show processlist 命令查看連接狀態發現，並不是。這個請求在正在准備的前10幾秒並沒有和 mysql 建立connection 連接。
那么我分析可能是 navicat 和數據庫服務器之間的通信連接斷掉了導致了，而根據 navicat 文檔說明，在連接高級設置這里有一個保持連接間隔（官方文檔-通過 ping 來保持連接。你可以在編輯框中設置 ping 與 ping 之間的間隔）的時長配置：將其設置成 240s。這樣每過240s，軟件就會像服務器發送心跳請求，以保證連接不被斷開。這樣我們就不會出現正在准備。。。等字樣了
