记录一次关于数据库配置导致的异常

在一个风和日丽的下午，接到客户反馈，数据查不到了，页面卡死，后台报错

 根据本人初步判断应该是客户进行了大批量的发送导致数据库连接池连接数不够用导致的，先查询nacos的druid配置：

看上去没啥问题，再看看数据库的最大连接数，发现只给了20.。。。。修改为1000（运维老哥感觉1000应该差不多）。

-- mysql服务器端和客户端在一次传送数据包的过程当中最大允许的数据包大小
show VARIABLES like '%max_allowed_packet%';

show variables like '%max_connections%';

-- 数据库表是否支持分区
show variables like '%partition%';

-- 查询输出表的详细信息
show table status like 'svr_sms_msg_detail';

-- 查询单个库中所有表磁盘占用大小
select
table_schema as '数据库',
table_name as '表名',
table_rows as '记录数',
truncate(data_length/1024/1024, 2) as '数据容量(MB)',
truncate(index_length/1024/1024, 2) as '索引容量(MB)'
from information_schema.tables
where table_schema='produce_center'
order by data_length desc, index_length desc;

 修改连接数后，使用压力测试发现问题依然存在。。。。。同时发现rocketmq居然有报错:

 仔细看发现有个system busy，这是不科学的啊（总共才十万左右）让运维老哥检查一下服务器，发现所有服务和中间件全部部在一个服务器上。。。（0_0）

然后运维大哥对服务器进行扩容啊啥的一顿操作，再次压测system busy发现没有了，但是数据库的那个还在（内心emo了）。。。然后就开始一顿百度，查到如下。

Communications link failure:The last packet successfully received from the server was 0 millisecond

最后加上了如下配置：

在/etc/my.cnf文件中[mysqld]部分增加，然后重启mysql

  max_connections=1000 //最大连接数

  wait_timeout=31536000 //负责超时控制的变量，默认8个小时，就是说MySQL的服务会在操作间隔8小时后断开，需要再次重连（这也是为啥上线前压测没问题吧。）使用autoReconnect=true来使得连接自动恢复，MySQL4及其以下版本适用。MySQL5中已经无效了，必须调整系统变量来控制了。

  interactive_timeout=31536000//服务器关闭交互式连接前等待活动的秒数

  net_read_timeout=6000

  net_write_timeout=6000

  max_allowed_packet=1G//一个数据包 

nacos的url：

autoReconnect=true&failOverReadOnly=false&useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=false&serverTimezone=GMT%2B8&rewriteBatchedStatements=true&allowPublicKeyRetrieval=true&testOnBorrow=true

再次测试问题完美解决！！！