max_allowed_packet超限会报“Lost connection to MySQL server during query”或“Packets larger than max_allowed_packet are not allowed”错误；需同步修改服务端my.cnf和客户端参数，并重启MySQL服务，且值须合理避免OOM。
max_allowed_packet 超了会报什么错
客户端发一个大 SQL（比如含超长 JSON、大 BLOB 插入、或 mysqldump 导出的单条 INSERT）时，如果超过当前限制，MySQL 服务端直接断连，常见错误是：Lost connection to MySQL server during query 或 Packets larger than max_allowed_packet are not allowed。注意：这个错不一定出现在你执行的那条语句上——可能前一条没报，下一条突然断，是因为连接复用+包累积导致缓冲区溢出。
改配置必须同时改客户端和服务端
max_allowed_packet 是个会话级变量，但它的上限由服务端全局值硬性限制。只改客户端（比如 MySQL 命令行加 --max-allowed-packet=64M）没用；只改服务端配置文件但没重启，也不生效。
- 服务端修改：编辑
my.cnf（Linux）或my.ini（Windows），在[mysqld]段写下max_allowed_packet = 64M（支持K/M/G单位） - 客户端修改（如需临时调高）：启动命令加
--max-allowed-packet=64M，或连接后执行SET SESSION max_allowed_packet = 67108864（单位字节） - 重要：改完
my.cnf后必须sudo systemctl restart mysql（或对应服务名），否则配置不加载
设多大才安全？别盲目堆高
设太大反而有风险：内存占用飙升、OOM 杀进程、甚至被用于 DoS 攻击。实际值取决于你的业务场景：
- 纯文本 SQL + 小字段：默认 4M 够用
- 导出/导入 dump 文件：按最大单条 INSERT 长度预估，一般 16M～64M 足够
- 存 Base64 图片或大 JSON：建议先压缩再存，或改用
LONGTEXT+ 分片逻辑，而不是把max_allowed_packet拉到 1G - 注意：该值不能超过服务端可用内存的 20%，且必须是 1024 的整数倍（MySQL 内部对齐要求）
验证改没改成功
改完重启后别信配置文件，直接连上去查：
SELECT @@global.max_allowed_packet, @@session.max_allowed_packet;
两个值都要看：@@global 是服务端上限，@@session 是当前连接实际生效值。如果后者明显小于前者，说明客户端启动时带了低值参数，或应用代码里显式设置了低值（比如 JDBC URL 里的 maxAllowedPacket 参数）。
有些 ORM（如 Django）或连接池（如 HikariCP）会自己设 session 级变量，这时候光改 my.cnf 还不够，得同步检查应用侧连接参数。
