本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
转载自夜明的孤行灯
本文链接地址: https://www.huangyunkun.com/2019/01/18/mysql-communications-exception-issue/
这周的一天早上一个定时任务突然报错，错误如下
### Error querying database. Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet successfully received from the server was 67,409 milliseconds ago. The last packet sent successfully to the server was 60,060 milliseconds ago. ### The error may exist in file [xxxxx.xml] ### The error may involve defaultParameterMap ### The error occurred while setting parameters 字面上看是数据库链接出了问题。
最近才把应用的数据库链接池从tomcat切换到druid，所以第一个怀疑的就是druid。
网上搜索搜索一下，发现大部分答案都基本是在连接取出之前需要进行测试，连接池一般支持这样的配置。稍微检查了一下，发现项目中已经配置了相关的配置，所以理论上不是这个问题导致的。
然后仔细研究了一下这个问题，发现这个问题其实蛮常见的，错误信息是一样的，但是具体对应的情况却是各不相同的。比如上文提到的是由于连接超时连接池再取出连接前没有进行测试，这只是一种情况，还有一种比较常见的情况是连接已经建立，但是由于慢查询或者服务器压力过大，导致长时间没有数据返回，占用数据库连接，进而达到数据库最大允许的连接数。
根据这个思路检查了一下数据库平台，从监控中可以看到有一个慢查询持续了60余秒，优化掉这个慢查询就解决了这个问题。
当然还有一些其他比较基本的情况，比如数据库地址错误，导致直接无法连接，或者是数据库配置有误，导致无法接受连接，不过这种问题一般出现在初次连接的时候，一般不会发生，在稳定运行的线上环境。
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
转载自夜明的孤行灯
本文链接地址: https://www.huangyunkun.com/2019/01/18/mysql-communications-exception-issue/