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 插入、或
mysql
dump 导出的单条 INSERT）时，如果超过当前限制，MySQL 服务端直接断连，常见错误是：
或
。注意：这个错不一定出现在你执行的那条语句上——可能前一条没报，下一条突然断，是因为连接复用+包累积导致缓冲区溢出。
改配置必须同时改客户端和服务端
是个会话级变量，但它的上限由服务端全局值硬性限制。只改客户端（比如 MySQL 命令行加
）没用；只改服务端配置文件但没重启，也不生效。
服务端修改：编辑
（Linux）或
（Windows），在
段写下
（支持
/
/
单位）
客户端修改（如需临时调高）：启动命令加
，或连接后执行
（单位字节）
重要：改完
后必须
（或对应服务名），否则配置不加载
设多大才安全？别盲目堆高
设太大反而有风险：内存占用飙升、OOM 杀进程、甚至被用于 DoS 攻击。实际值取决于你的业务场景：
纯文本 SQL + 小字段：默认 4M 够用
导出/导入 dump 文件：按最大单条 INSERT 长度预估，一般 16M～64M 足够
存 Base64 图片或大 JSON：建议先压缩再存，或改用
+ 分片逻辑，而不是把
拉到 1G
注意：该值不能超过服务端可用内存的 20%，且必须是 1024 的整数倍（MySQL 内部对齐要求）
验证改没改成功
改完重启后别信配置文件，直接连上去查：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
两个值都要看：
是服务端上限，
是当前连接实际生效值。如果后者明显小于前者，说明客户端启动时带了低值参数，或应用代码里显式设置了低值（比如 JDBC URL 里的
参数）。
有些 ORM（如 Django）或连接池（如 HikariCP）会自己设 session 级变量，这时候光改
还不够，得同步检查应用侧连接参数。
Lost connection to MySQL server during queryPackets larger than max_allowed_packet are not allowedmax_allowed_packet--max-allowed-packet=64Mmy.cnfmy.ini[mysqld]max_allowed_packet = 64MKMG--max-allowed-packet=64MSET SESSION max_allowed_packet = 67108864my.cnfsudo systemctl restart mysqlLONGTEXTmax_allowed_packetSELECT @@global.max_allowed_packet, @@session.max_allowed_packet;@@global@@sessionmaxAllowedPacketmy.cnf