mysql突然无法连接,mysql连接出现1045错误 _为什么软件关闭数据库连接

前言最近遇到在将本地的项目部署到服务器上之后遇到的一个奇怪问题
在部署完成后，网站当时可以正常工作，但是第二天访问网站的时候却会遇到一个500 Server Error 。
从日志中可以看出是MySQL数据库出现了异常

文章插图
翻译如下:
最后一个数据包在 83827560 ms 之前被成功接收，最后一个数据包在83827560 ms 之前被成功发送。比服务的配置参数wait_timeout的值要长。
日志中给出的建议如下

文章插图
翻译如下：
你应考虑在程序中进行数据库操作之前检验数据库连接的有效性或者将数据库的autoReconnect属性设置为true来避免这个问题
关于wait_timeout和autoReconnect下面我们会依次分析介绍！
原因分析我们进入mysql的命令行查询超时时间

文章插图
28800单位是秒转化成小时就是8小时
看出MySQL的默认设置，当一个连接的空闲时间超过8小时后，MySQL就会断开该连接
所以发现问题出在如果超过这个wait_timeout时间(默认是8小时)对数据库没有任何操作，那么MySQL会自动关闭数据库连接以节省资源
数据库连接自动断开的问题确实是在第二天发生了，也就是在一个晚上没有对数据库进行操作(显然超过了8小时)的情况下发生的这个问题

文章插图
大家用命令show processlist; 可以查看Sleep状态的进程Sleep，同时可以看到每个进程Sleep多久了：

文章插图
下面介绍下解决和优化办法！
解决方法1.autoReconnect这个参数表示在mysql超时断开连接后会自动重新连接
配置的话，只需要在连接mysql的语句写上autoReconnect=true
jdbc:mysql://127.0.0.1:3306/stock_tweet?autoReconnect=true 下面是MySQL官网对autoReconnect的解释:

文章插图
同时可以看到官网不推荐使用这个参数，因为它有一些副作用
具体介绍下：
原有连接上的事务将会被回滚，事务的提交模式将会丢失原有连接持有的表的锁将会全部释放原有连接关联的会话Session将会丢失，重新恢复的连接关联的将会是一个新的会话Session原有连接定义的用户变量将会丢失原有连接定义的预编译SQL将会丢失原有连接失效，新的连接恢复后，MySQL将会使用新的记录行来存储连接中的性能数据2.修改配置涉及到两个配置参数interactive_timeout和wait_timeout
wait_timeout 指的是mysql在关闭一个非交互的连接之前所要等待的秒数
interactive_time 指的是mysql在关闭一个交互的连接之前所要等待的秒数
对于交互和非交互连接，说得直白一点就是，通过mysql客户端连接数据库是交互式连接，通过jdbc连接数据库是非交互式连接。
配置方法：
1.会话方式
msyql> set global wait_timeout=2880000;msyql> set global interactive_timeout=2880000;这种方式只对当前会话生效
2.修改配置文件方式
修改/etc/my.cnf文件，在 [mysqld] 节中设置：

文章插图
之后再重启下服务器就好了
注意：
将wait_timeout这个值设置得大了，可能会导致空闲连接过多。
如果你的MySQL Server有大量的闲置连接，他们不仅会白白消耗内存，而且如果连接一直在累加而不断开，最终肯定会达到MySQL Server的连接上限数，这会报'too many connections'的错误。