应用日志出现 MySQL server has gone away，不等于数据库一定宕机。MySQL官方文档把它和 Lost connection to MySQL server during query 放在同一类问题中，最常见原因是连接空闲太久，被服务器超时关闭。
不过，大数据包、网络设备回收连接、连接池复用失效连接、mysqld崩溃重启，也会产生相似报错。正确处理方式是先把发生时间、连接状态和服务器日志对应起来，再改参数。
先确认MySQL有没有重启或退出
从服务状态和错误日志开始：
sudo systemctl status mysql --no-pager -l
sudo journalctl -u mysql --since "30 minutes ago" --no-pagerRHEL系或部分安装方式的单元名可能是 mysqld，容器部署则应查看容器状态与日志。继续读取运行时间：
SHOW GLOBAL STATUS LIKE 'Uptime';故障刚发生，Uptime却很短，说明MySQL可能重启过。此时要检查OOM、磁盘空间、文件系统和崩溃日志，不能把问题简单归因于连接超时。
先确认服务是否重启，是区分数据库端故障与单条连接失效的关键分界线。
空闲连接超时是最常见原因
MySQL 8.4官方文档说明，默认情况下连接空闲八小时后，服务器会关闭它，对应变量是 wait_timeout。实际服务器可能被面板、配置文件或托管平台修改，必须读取当前值：
SHOW SESSION VARIABLES LIKE 'wait_timeout';
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';应用连接池保存连接的时间超过数据库、代理或防火墙允许的空闲时间，再次复用时就可能发现连接已经失效。更稳妥的做法是让连接池在借出连接前做有效性检查，并把连接最大生命周期设置得略短于链路中最小的超时值。
单纯把 wait_timeout 调得很大，会让大量空闲连接长期占用资源。优先修正连接池回收与重连逻辑，再评估是否需要调整服务器超时。
大SQL和BLOB要检查max_allowed_packet
MySQL收到过大或顺序异常的数据包时，可能主动关闭连接。先读取当前限制：
SHOW VARIABLES LIKE 'max_allowed_packet';MySQL 8.4文档列出的默认服务端值为64MB，但实际环境和客户端限制可能不同。批量INSERT、大BLOB、备份导入和超长SQL容易触发。不要看到报错就无限增大参数，先记录失败请求的真实大小，并尝试减小单批记录数。
确实需要提高时，要同时核对服务端和客户端配置。修改全局变量只影响后续新连接的情况也很常见，应用连接池需要重新建立连接后再验证。
网络和应用连接复用也会断开
数据库与应用不在同一台服务器时，还要检查安全组、防火墙、NAT、负载均衡或数据库代理的空闲连接回收时间。短时间网络抖动通常不会留下MySQL重启记录，却可能让客户端读写超时。
应用自身也可能在关闭连接后继续查询，或在fork出的多个子进程间共享同一数据库连接。MySQL官方明确把这些情况列为常见原因。每个子进程应建立自己的连接，连接失效后的重试还要限制次数，避免故障时形成重试风暴。
需要把应用和数据库拆开复现网络问题时，可临时对比 萤光云 与 LightNode 的节点和网络条件。测试必须记录客户端、数据库端和中间链路的超时设置，不能只换一台服务器就下结论。
按错误出现的时间规律定位根因
每次空闲固定时长后第一次查询失败，更像连接池与超时不匹配；只在上传大文件或批量写入时失败，更像数据包或请求过大；所有连接同时断开，并且Uptime重新计时，应优先调查mysqld重启；跨网络访问随机失败，则要把TCP超时、丢包和中间设备纳入证据链。
可以同时记录：
SHOW GLOBAL STATUS LIKE 'Aborted_%';
SHOW GLOBAL STATUS LIKE 'Connections';
SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'max_allowed_packet';这些状态只能帮助缩小范围，不能单独证明某次报错原因。最终还要用同一时间窗口的应用日志、MySQL错误日志和系统日志相互印证。
修改后必须用新连接完成验收
调整连接池、超时或数据包配置后，重建应用连接，再分别测试短查询、超过原空闲周期的连接和原本失败的大请求。不要只在MySQL命令行执行一次 SELECT 1 就宣布恢复。
验收标准是原故障场景可以稳定完成，MySQL没有异常重启，连接池能淘汰失效连接，错误日志不再出现对应时间点的通信或崩溃异常。 生产环境还应为断连错误率、数据库重启和连接数设置告警。
FAQ
提高wait_timeout一定能解决吗？
不一定。连接可能被代理、防火墙或客户端更早关闭，也可能来自大数据包和服务重启。应先确认断开位置。
max_allowed_packet越大越好吗？
不是。它应覆盖业务合理的单次请求，同时避免无限放大异常SQL或导入任务。大批量写入更适合拆分处理。
应用自动重连后就不用管了吗？
自动重连可能掩盖根因，而且事务、会话变量和临时表状态可能已经丢失。重连逻辑必须理解当前操作是否可以安全重试。
MySQL没有重启，为什么所有应用都同时报错？
共享的数据库代理、NAT、防火墙或网络链路也可能同时断开连接，需要对齐多端日志和连接超时设置。
温馨提示
server has gone away是结果，不是唯一原因。不要一上来同时增大wait_timeout和max_allowed_packet；先判断超时、数据包、网络和重启中的哪一类证据最明确，再做最小改动。
