max_allowed_packet过小是触发2006错误的主因，本质是服务端拒收超长数据包而非连接中断；需同步调优服务端（my.cnf中[mysqld]段）和客户端（如--max-allowed-packet参数），并重启MySQL生效。
max_allowed_packet 设置过小是导致插入大字段（如长文本、BLOB、LONGTEXT）时触发 2006 - MySQL server has gone away 的最常见原因——不是连接断了，而是服务端直接拒收超长数据包。
为什么改 max_allowed_packet 能解决插入失败？
MySQL 在接收客户端请求时，会把整条 SQL（含所有参数值）打包成一个通信包。如果插入的字段内容（比如一段 6MB 的 JSON 或图片 Base64）超过 max_allowed_packet 限制，服务端连解析都不做，直接断开连接并报错 2006。此时你看到的 “gone away” 是假象，本质是 PacketTooBigException。
max_allowed_packet 需要客户端和服务端同时设对
这个参数不是只配服务端就完事。MySQL 客户端（如 Python 的 pymysql、Java 的 mysql-connector-java、命令行 mysql）也有自己的接收缓冲区，默认和服务器一致，但某些驱动会忽略服务端值，按自身默认（通常是 4MB）硬扛。
- 服务端生效需在
[mysqld]段配置：max_allowed_packet = 64M（单位支持M或字节） - 客户端生效方式因工具而异：
– 命令行导入时加--max-allowed-packet=64M：mysql --max-allowed-packet=64M -u root db < dump.sql
– Pythonpymysql初始化连接时显式传参：connect(..., max_allowed_packet=67108864)
– JDBC URL 中加参数：?maxAllowedPacket=67108864 - 只改服务端配置却不重启 MySQL，或没同步客户端设置，依然会失败
怎么确认当前生效值？别信配置文件，要看运行时
配置文件写对了不等于生效。必须查运行中的变量：
mysql> SELECT @@max_allowed_packet; +----------------------+ | @@max_allowed_packet | +----------------------+ | 4194304 | +----------------------+
返回 4194304 就是默认 4MB。如果刚改了配置但这里没变，说明：
– 没重启 MySQL（Linux 下 sudo systemctl restart mysql；Windows 下重启服务）
– 改错了段落（必须在 [mysqld] 下，不是 [client] 或 [mysql]）
– 配置文件路径不对（用 mysqld --help --verbose | grep "Default options" 确认实际加载路径）
设多大才够？别盲目堆高，注意副作用
设成 1G 看似一劳永逸，但有实际风险：
- 内存压力：每个连接都会预留该大小的缓冲区（哪怕不用），并发高时易 OOM
- 复制延迟：主从环境中，大包传输更易受网络抖动影响，可能拖慢
binlog重放 - 安全边界：过大的包可能被用于 DoS 类攻击，生产环境建议控制在
64M内 - 真正需要调大的场景其实很明确：批量插入含
MEDIUMTEXT以上字段、还原大mysqldump文件、上传富文本/附件元数据
临时调试可先用 SET GLOBAL max_allowed_packet = 67108864，验证通过再写入配置文件——但要注意该语句在 MySQL 8.0+ 中要求 SYSTEM_VARIABLES_ADMIN 权限，且重启后失效。
max_allowed_packet 不是万能开关，它只管“包大小”，不管“连接时长”。如果插入操作本身耗时极长（比如单条 INSERT 含几百万行子查询），即使包不大，也会因 wait_timeout 触发真正的连接断开。那种情况得另调超时参数，或者拆分语句。
