在MySQL故障类问题中，“MySQL server has gone away”类的问题常见且问题比较典型，今天我们就一些来讨论如何排查和解决这个问题。

当产生MySQL服务器服务丢失类错误告警，并且无法连上数据库时，可能情况是MySQL监听程序mysqld服务器端由于超时并关闭了连接。默认情况下，如果没有任何新连接以及交互，MySQL会在八小时（28800秒）后关闭连接，从而会导致这个问题。

错误消息

基于个不同的环境，这类错误可能告警可能也不大相同。当也有可能，是由于应用层的编程逻辑或者连接网络问题导致的故障，为了进一步排查真正的原因不能光凭客户端一行告警信息来断定问题原因并直接进行后续解决步骤。详细检查完整的客户端以及数据服务器日志来进行问题定位常常是非常必要的和最高效省时的措施。MySQL服务器服务丢失类错误日志常见的有：

General error: 2006 MySQL server has gone away

Error Code: 2013. Lost connection to MySQL server during query

Warning: Error while sending QUERY packet

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

问题解决

MySQL服务器丢失类错误和MySQL服务器以及客户的一些设置有关，这些设置直接或者间接导致一个MySQL连接的持久时间。

MySQL等待超时

MySQL服务器丢失类错误的最常见的原因是MySQL wait_timeout设置。MySQL wait_timeout是服务器在非交互的情况下关闭连接的等待时间（秒数）。通常应该确保 wait_timeout没有设置得太低。如果没有专门的手动配置，MySQL官方默认值为28800秒。为了提高性能，通常会将该值降低。在不影响数据库连接的情况下将wait_timeout设置得越低，MySQL数据库效率越好。另外，一些相关的配置项net_read_timeoutnet_write_timeout和Interactive_timeout也影响等待超时。wait_timeout和这些参数都可以在my.cnf进行手动指定，一个简单配置为：

wait_timeout=90
net_read_timeout=90
net_write_timeout=90
interactive_timeout=300
connect_timeout=90

MySQL连接超时

另外还需要配置，客户端的连接超时设置，本文我们以PHP为例（其他语言请查看对应文档设置），查看php.ini配置文件，其中可以将找到MySQL配置选项，在其中有个mysql.connect_timeout连接超时配置项，需要确保其设置和服务器端的wait_timeout的设置相一致。mysql.connect_timeout不仅用于连接超时，也是在等待MySQL服务器的第一个响应时。

一般手动增加mysql.connect_timeout等于或大于MySQL wait_timeout并设置配置连接保持配置项mysql.allow_persistent为启用（默认启用1）。

mysql.connect_timeout=90
mysql.allow_persistent=1

另外，还需要调整PHP的default_socket_timeout。

默认情况下，PHP default_socket_timeout设置流的读取超时设置为60秒。此默认值适用于未设置其他超时值的所有流，所以如果你的应用是一个需要耗时的长时查询链接，会在60s后断开，并报：错误消息2006–MySQL Server has gone away。

default_socket_timeout=90

另外php.ini中的max_execution_time和 max_input_time也可能会导致连接丢失类错误。如果PHP的执行时间高于max_execution_time设置，那么MySQL服务器也可能会主动断开连接。

max_execution_time = 90
max_input_time = 90

MySQL最大允许数据包

max_allowed_pa?cket是一个数据包的最大尺寸，其默认大小4MB，该设置防止MySQL服务器捕获大的（可能是不正确的）数据包。从MySQL 8开始，默认值已增加到16MB。如果mysqld收到太大的数据包，它会认为出现问题并关闭连接。如果你的应用中确实存在大尺寸的数据包，则也需要对此单独配置：在my.cnf中添加并设置max_allowed_pa??cket值（主意指定M，G等单位，最大支持1G） ，然后重新启动MySQL：

max_allowed_packet = 512M

MySQL innodb_log_file_size

另外也需要注意设置my.cnf 配置中的MySQL变量innodb_log_file_size。其设置应该为innodb_buffer_pool_size 的25% （如果可能的话，不少于20%）。该值越大从数据库崩溃中恢复所需的时间就越长。

例如，如果缓冲池大小设置

innodb_buffer_pool_size = 16G

并且innodb_log_files_in_group设置仍设置为建议的默认值2个文件

innodb_log_files_in_group = 2

那么innodb_log_file_size应设置为2G。

该设置会创建两2个日志文件，每个文件大小为2GB，相当innodb_buffer_pool_size=16G的25% 。

其他原因

除了以上配置项目，在事件中仍然有其他原因也可能对导致服务器连接丢失类错误。

远程MySQL连接

错误有时仅表明存在更深层次的潜在问题。例如， 与第三方服务的远程MySQL连接，这时需要和相关对接系统进行联合配置调试排查。

MySQL数据库字符集和排序规则

在某些情况下也有可能会由于数据库字符集导致的服务器连接丢失类错误。比如可以将默认数据库字符集更改为latin1并将默认排序规则更改为latin1_general_ci，一般可以解决此类问题。

超出MySQL max_connections 设置

Max_connections设置允许的同时客户端连接的最大数量，如果出现连接数量不够的情况下可以适当的加大这个数值。但是该设置并不是设置的越大越好，对于一个高QPS的数据库系统，如果设置的数值过大，可能会出现内存和其他资源耗尽的情况（相当于Dos攻击）。

笔者曾经维护的一个高并发系统的初期由于最大连接数设置不合理，会出现高峰期服务器负载几十，并且导致数据库无法连接，设置无法通过SSH连接到服务器进行维护，只能通过脚本在负载过高时候自动重启服务来进行缓解的蹩脚处理方法。

根据实践经验，一般可以将max_connections临时预设置为大约之前最大同时客户端连接数的两倍，然后进行观察系统运行情况。例如，最大并发客户端连接数为120，如果系统可以正常运行一段时间（一周或者一个月），可以将设置再改为max_connections=250，如此迭代，直至找到最佳的设置值。

总结

本文虫虫给大家介绍了服务器连接丢失类错误的常见原因以及解决的对策，基于此可以解决最常见的该问题，当然这还没有详细到覆盖所有的场景，当遇到这类问题时候还需要具体问题具体分析，辩证排查和解决。