max_allowed_packet超限会报“MySQL server has gone away”错误，日志提示“Packets larger than max_allowed_packet are not allowed”；可通过SELECT @@max_allowed_packet查询当前值，用SET GLOBAL临时修改，或在my.cnf的[mysqld]段永久配置。
max_allowed_packet 超了会报什么错
客户端往 MySQL 写入或读取大字段（比如长 JSON、大 BLOB、超长 INSERT 语句）时，如果数据包超过服务端限制，直接断连并报错：MySQL server has gone away。注意这不是网络问题，而是服务端主动拒绝——日志里通常跟着 Packets larger than max_allowed_packet are not allowed 这句提示。
怎么查当前值和临时改大
先确认当前设置是否真成了瓶颈：
SELECT @@max_allowed_packet;
返回值单位是字节。常见默认值是 4MB（4194304），不够存一个 10MB 的图片 base64 字符串。
临时生效（重启后失效）用 SQL 命令：
-
SET GLOBAL max_allowed_packet = 67108864;（设为 64MB） - 必须有
GLOBAL权限；普通用户会报Access denied - 客户端连接需重连才能感知新值（已建立的连接仍按旧值限制）
永久修改必须改配置文件
只执行 SET GLOBAL 是治标不治本，mysqld 一重启就回退。真正要持久化，得改 MySQL 配置文件（通常是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）：
- 在
[mysqld]段落下加一行：max_allowed_packet = 64M（支持M/G后缀） - 改完必须重启服务：
sudo systemctl restart mysql（或mysqld） - 别漏掉客户端侧：如果用的是 mysql 命令行工具，它也有自己的
max_allowed_packet，需在[client]段同步设，否则导入大 SQL 文件时仍会失败
为什么设太大反而容易出问题
这个值不是越大越好。设成 1G 看似保险，但实际埋了两个坑：
- 每个连接都会预留对应大小的内存缓冲区，连接数多时极易 OOM（尤其在低配服务器上）
- 某些老版本 MySQL（如 5.6）对超大 packet 处理有 bug，可能触发崩溃或复制中断
- 应用层没做校验时，错误地传入超大无效数据，会卡住连接、拖慢整个实例
建议按业务最大单条数据体积 * 1.5 来设，而不是拍脑袋填个 1G。上线前务必在测试环境模拟真实负载压测内存和连接稳定性。
