http://zeusami.iteye.com/blog/1112827
MySQL第二天早上第一次連接超時報錯，解決方法com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure Last packet sent to the server was 0 ms ago
最近碰到一個mysql5數據庫的問題。就是一個標準的servlet/tomcat網絡應用，後臺使用mysql數據庫。問題是待機一晚上後，第二天早上第一次登錄總是失敗。察看日誌發現如下錯誤：
“com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
Last packet sent to the server was 0 ms ago.”
經過一番調研，發現很多人都碰到過類似問題，但網上令人滿意的回答並不多。mysql網站上的提問也很多，但並沒有正確答案；百度知道上倒是有一個近似正確的回答。現將本人的解決辦法總結一下：
上述問題是由mysql5數據庫的配置引起的。mysql5將其連接的等待時間(wait_timeout)缺省爲8小時。在其客戶程序中可以這樣來查看其值：
mysql﹥
mysql﹥ show global variables like 'wait_timeout';
+---------------+---------+
| Variable_name | Value |
+---------------+---------+
| wait_timeout | 28800 |
+---------------+---------+
1 row in set (0.00 sec)
28800 seconds，也就是8小時。
如果在wait_timeout秒期間內，數據庫連接(java.sql.Connection)一直處於等待狀態，mysql5就將該連接關閉。這時，你的Java應用的連接池仍然合法地持有該連接的引用。當用該連接來進行數據庫操作時，就碰到上述錯誤。這解釋了爲什麼我的程序第二天不能登錄 的問題。
你可能會想到在tomcat的數據源配置中有沒有辦法解決？的確，在jdbc連接url的配置中，你可以附上“autoReconnect=true”，但這僅對mysql5以前的版本起作用。增加“validation query”似乎也無濟於事。
本人覺得最簡單的辦法，就是對症下藥：既然問題是由mysql5的全局變量wait_timeout的缺省值太小引起的，我們將其改大就好了。
查看mysql5的手冊，發現對wait_timeout的最大值分別是24天/365天(windows/linux)。以windows爲 例，假設我們要將其設爲21天，我們只要修改mysql5的配置文件“my.ini”(mysql5 installation dir)，增加一行：wait_timeout=1814400
需要重新啓動mysql5。
linux系統配置文件：/etc/my.cnf
測試顯示問題解決了。
也可以直接設置
mysql修改wait_timeout
mysql mysql> show global variables like 'wait_timeout';
其默認值爲8小時
mysql的一個connection空閒時間超過8小時，mysql會自動斷開該連接。
1.修改配置
vi /etc/my.cnf
[mysqld] wait_timeout=10
# /etc/init.d/mysql restart
2.直接用sql命令行修改 mysql> set global wait_timeout=604800;
除了wait_timeout，還有一個'interactive_timeout'
同樣可以執行SHOW GLOBAL VARIABLES LIKE 'interactive_timeout'來查詢
執行set global interactive_timeout=604800;來設置
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure Last packet sent to the server was 0 ms ago
最近碰到一個mysql5數據庫的問題。就是一個標準的servlet/tomcat網絡應用，後臺使用mysql數據庫。問題是待機一晚上後，第二天早上第一次登錄總是失敗。察看日誌發現如下錯誤：
“com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
Last packet sent to the server was 0 ms ago.”
經過一番調研，發現很多人都碰到過類似問題，但網上令人滿意的回答並不多。mysql網站上的提問也很多，但並沒有正確答案；百度知道上倒是有一個近似正確的回答。現將本人的解決辦法總結一下：
上述問題是由mysql5數據庫的配置引起的。mysql5將其連接的等待時間(wait_timeout)缺省爲8小時。在其客戶程序中可以這樣來查看其值：
mysql﹥
mysql﹥ show global variables like 'wait_timeout';
+---------------+---------+
| Variable_name | Value |
+---------------+---------+
| wait_timeout | 28800 |
+---------------+---------+
1 row in set (0.00 sec)
28800 seconds，也就是8小時。
如果在wait_timeout秒期間內，數據庫連接(java.sql.Connection)一直處於等待狀態，mysql5就將該連接關閉。這時，你的Java應用的連接池仍然合法地持有該連接的引用。當用該連接來進行數據庫操作時，就碰到上述錯誤。這解釋了爲什麼我的程序第二天不能登錄 的問題。
你可能會想到在tomcat的數據源配置中有沒有辦法解決？的確，在jdbc連接url的配置中，你可以附上“autoReconnect=true”，但這僅對mysql5以前的版本起作用。增加“validation query”似乎也無濟於事。
本人覺得最簡單的辦法，就是對症下藥：既然問題是由mysql5的全局變量wait_timeout的缺省值太小引起的，我們將其改大就好了。
查看mysql5的手冊，發現對wait_timeout的最大值分別是24天/365天(windows/linux)。以windows爲 例，假設我們要將其設爲21天，我們只要修改mysql5的配置文件“my.ini”(mysql5 installation dir)，增加一行：wait_timeout=1814400
需要重新啓動mysql5。
linux系統配置文件：/etc/my.cnf
測試顯示問題解決了。
也可以直接設置
mysql修改wait_timeout
mysql mysql> show global variables like 'wait_timeout';
其默認值爲8小時
mysql的一個connection空閒時間超過8小時，mysql會自動斷開該連接。
1.修改配置
vi /etc/my.cnf
[mysqld] wait_timeout=10
# /etc/init.d/mysql restart
2.直接用sql命令行修改 mysql> set global wait_timeout=604800;
除了wait_timeout，還有一個'interactive_timeout'
同樣可以執行SHOW GLOBAL VARIABLES LIKE 'interactive_timeout'來查詢
執行set global interactive_timeout=604800;來設置