The last packet successfully received from the server was 1,002 milliseconds ago. The last packet sent successfully to the server was 1,001 milliseconds ago
sql查询太频繁。。。
解决办法：加上autoReconnect=true.貌似没什么卵用
jdbc:mysql://10.10.10.10:3306/mydb?autoReconnect=true
调整大小：
连接池配置小于mysql中的配置：
查看当前连接数;
show status like 'Threads%';
如果你只是个DBA，你会想着，为什么数据库连接自己断了，是不是哪里有配置，我得去看看，那么你得到的解决方案-可能就是这样的
#my.cnfwait_timeout=31536000 interactive_timeout=31536000
加大wait_timeout的时间。
But 现实环境中需要你考虑的是：
你设置多久检查一次连接有效的时间 依据是什么？
默认加大/减小wait_timeout除了解决当前问题，会不会带来其他影响？
个人当前觉得此题 第一需考虑的是：
你业务当前高峰期mysql_connection是多少？保留多久connection在高峰期都不会撑爆你数据库连接池？
如果你知道这个池-那么是改mysql ？还是改c3p0？还是双管齐下都是有据可循且不会带来后遗症的-最佳解决方案
如我当前有环境，一个现网的后台管理系统，使用人数在50以内，那么我wait_timeout 就是默认8小时，c3p0不用做连接有效性检查等，都是万事ok的。
一个EPG前台管理系统，用户量在300万以内，如果我wait_timeout为8小时，那我一到高峰期肯定就是死翘翘的，会有太多的TCP连接没关闭，
数据库连接数肯定是不够的。
因EPG的一个访问-一次对数据库操作量不大，查询完数据就完成ok啦，wait_timeout 设置在120s内应该是够用啦，那么相对应的c3p0中 设置小于wait_timeout 的时间有效性检查 -就能确保获取到连接是有效的。
请根据业务场景，来配置参数，不要解决了A问题，带来了B问题。
