最近碰到一个 mysql5 数据库的问题。就是一个标准的 servlet/tomcat 网络应用，后台使用 mysql 数据库。问题是待机一晚上后，第二天早上第一次登录总是失败。察看日志发现如下错误： “ com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:Communicat
最近碰到一个 mysql5 数据库的问题。就是一个标准的 servlet/tomcat 网络应用，后台使用 mysql 数据库。问题是待机一晚上后，第二天早上第一次登录总是失败。察看日志发现如下错误：
“ com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:Communications link failure
Lastpacket 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 |
+---------------+---------+
1row in set (0.00 sec)
28800seconds ，也就是 8 小时。
如果在 wait_timeout 秒期间内，数据库连接 (java.sql.Connection) 一直处于等待状态， mysql5 就将该连接关闭。这时，你的 Java 应用的连接池仍然合法地持有该连接的引用。当用该连接来进行数据库操作时，就碰到上述错误。这解释了为什么我的程序第二天不能登录的问题。
你可能会想到在 tomcat 的数据源配置中有没有办法解决？的确，在 jdbc 连接 url 的配置中，你可以附上“ autoReconnect=true” ，但这仅对 mysql5 以前的版本起作用。增加“ validationquery” 似乎也无济于事。
本人觉得最简单的办法，就是对症下药：既然问题是由 mysql5 的全局变量 wait_timeout 的缺省值太小引起的，我们将其改大就好了。
查看 mysql5 的手册，发现对 wait_timeout 的最大值分别是 24 天 /365 天 (windows/linux) 。以 windows 为例，假设我们要将其设为 21 天，我们只要修改 mysql5 的配置文件“ my.ini”(mysql5installation dir) ，增加一行： wait_timeout=1814400
需要重新启动 mysql5 。
linux 系统配置文件： /etc/my.cnf