前言

之前在发生产的时候遇到一个很奇怪的问题，一个查询query方法明明之前用的很好，突然有一天报错，导致整条业务都不能运行，后面发现是因为配置的原因。

故障回顾

不知道大家遇到过这个问题没有,当时我们在发布一个patch补丁中使用了这个query方法，直接在启动的时候报错'The last packet successfull xxxx xxxx',我们第一时间是怀疑是不是网络的问题（因为这个方法之前使用没有问题），然后重启还是报错。 

分析问题

因为看报错是超时的缘故，回想项目已经上线了一年，上次使用这个方法还是在半年之前，猜测是数据量加大，加上这个SQL是全表扫描，为什么是全表扫码，因为条件是JSON 结构啊,最后发现竟然是数据量大，导致MySQL返回查询结构超时了。详情是因为”net_write_timeout“这个配置 

客户服务器配置：

解决方法

不再使用这个方法，使用ES索引查询 或者 换索引表查询。

反思

MySQL 超时配置有很多，不单单只是Server端的配置。 MySQL 相关超时配置

• wait_timeout：服务器等待活动连接的最长时间（秒）。在超过这个时间后，MySQL 会关闭未活动的连接。默认值：28800 秒（8 小时）
• interactive_timeout：MySQL 客户端工具（如 MySQL shell）与服务器的连接超时。28800 秒（8 小时）
• connect_timeout：服务器等待连接建立完成的时间（秒）。
• net_read_timeout 和 net_write_timeout：服务器等待数据包读写完成的超时时间（秒）。