mysql错误2006“server has gone away”主因是服务端主动断连，常见于max_allowed_packet过小导致数据包被拒，或wait_timeout/interactive_timeout过短引发空闲连接超时关闭；需同步调大服务端与客户端的包限制，并合理设置超时参数配合连接池心跳。
Server has gone away 错误到底是什么原因
这不是网络断开或服务器宕机，而是 MySQL 主动关闭了连接——通常因为客户端发来的数据包超长，或连接空闲太久被服务端踢掉。Server has gone away 是 MySQL 的标准错误码 2006，背后大概率是 max_allowed_packet 不够，或 wait_timeout/interactive_timeout 过短。
调大 max_allowed_packet 时必须同步改客户端和服务器
只改 my.cnf 里的 max_allowed_packet 不够。MySQL 客户端（比如 Python 的 pymysql、PHP 的 mysqli）也有自己的包大小限制，且默认远小于服务端值。服务端设成 64M，但 PHP 默认只允许 16M，照样报错。
- 服务端配置（
/etc/mysql/my.cnf或/etc/my.cnf）加：[mysqld] max_allowed_packet = 64M
- 客户端也要显式设置：Python 中用
pymysql.connect(..., max_allowed_packet=67108864)；PHP 中用mysqli_options($conn, MYSQLI_OPT_MAX_PACKET_SIZE, 67108864) - 改完重启 MySQL：
sudo systemctl restart mysql，并确认生效：SHOW VARIABLES LIKE 'max_allowed_packet';
wait_timeout 和 interactive_timeout 不是“越长越好”
这两个参数控制空闲连接存活时间，默认通常是 28800 秒（8 小时），但很多应用连接池没做心跳或复用逻辑，实际连接可能卡在“半死不活”状态。盲目调到 24 小时反而会让失效连接堆积，最终耗尽 max_connections。
- 先查当前值：
SHOW VARIABLES LIKE '%timeout%'; - 生产环境建议设为 300–600 秒（5–10 分钟），配合应用层连接池的
testOnBorrow或validationQuery=SELECT 1 -
wait_timeout影响普通连接，interactive_timeout影响带CLIENT_INTERACTIVE标志的连接（如 MySQL CLI），两者常设相同值 - 注意：修改后仅对新连接生效，已有连接仍按旧 timeout 计时
容易被忽略的底层细节：packet 拆分与重连陷阱
MySQL 协议本身不支持自动分包，max_allowed_packet 是单个 packet 的上限。如果应用尝试 INSERT 一个 100MB 的 JSON 字段，即使服务端设了 128M，也得确保整个字段未被中间件（如代理、ORM 序列化层）额外编码膨胀。更隐蔽的是：某些 ORM（如 Django）在事务中执行多条语句时，会把多条 SQL 拼成一个大 packet 发送，触发截断。
- 用
tcpdump -i lo port 3306 -w mysql.pcap抓包，看是否出现 TCP retransmission 或 abrupt FIN - 检查应用日志里出错前的 SQL 是否含超长
INSERT ... VALUES (...)或LOAD DATA INFILE - 不要依赖自动重连（如
mysql_ping()）来掩盖问题——它不能恢复已中断的事务上下文
