mysql The last packet successfully received from the server was xx milliseconds ago

mysql服务器最近老是报错，内容如下：

The last packet successfully received from the server was 65,502,275 milliseconds ago.  The last packet sent successfully to the server was 65,502,276 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in  your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

主要的意思是：数据库有长连接，由于长时间没有使用，并且空闲时间超过了wait_timeout设置的时间。 数据库到了wait_timeout设定的时间，自动释放了链接。

客户端还有这个长连接，客户端使用这个长连接向mysql数据库发送消息，可是这个链接数据库服务器端已经释放了，所以爆出上面的错误.

这篇文章介绍的是连接池处理不当造成的，还有localhost改变成127.0.0.1解决办法，具体原因请看

如果你刚好在数据库超时的第一时间内看到日志记录的话那么，第一次超时发生的错误就是这样的：

ERROR [org.hibernate.util.JDBCExceptionReporter] - Communications link failure

Last packet sent to the server was 0 ms ago.

如果不是第一次超时后执行，以后每次报错就变成嵌套的错误了，就是下面这样：

ERROR [org.hibernate.util.JDBCExceptionReporter] -

 No operations allowed after connection closed.Connection was implicitly closed due to underlying exception/error:

查看wait_timeout语法

在 MySQL 8.0 版本以下，wait_timeout 的默认值是 28800 秒（8 小时）。

在 MySQL 8.0 版本及以上，wait_timeout 的默认值改成了 86400 秒（24 小时）。

可以通过以下 SQL 语句查看当前的 wait_timeout 值：

SHOW VARIABLES LIKE 'wait_timeout';

解决办法：

由于项目中代码比较多，查找哪一个长连接没有释放很麻烦，过程如下：

（1）查看报错日志的详细信息，看关系到哪一个dao类出现的问题

（2）然后将mysql连接池最大、最小数据设置成3,1.

（3）然后打开3个浏览器，进行操作业务，出发dao层

（4）发现项目确实很慢，然后详细看了一下代码，确实由于一个地方连接池没有关闭，导致链接一直存在，没有释放。

原理分析：如果数据链接池中有4个链接，然后有4个用户打开了链接，他们都没有释放链接，一直保持链接。新用户来了之后，在连接池中寻找链接，可是没有可用的链接。