如何解决MySQL报错:Got a packet bigger than max_allowed_packet?

必须同时调大服务端和客户端的max_allowed_packet，只改一端大概率继续报错；查当前值应执行SHOW VARIABLES LIKE 'max_allowed_packet'，返回值单位为字节，需区分会话值与全局值（@@global.max_allowed_packet），临时可用SET GLOBAL/SESSION修改，永久修改须在my.cnf的[mysqld]段配置并重启服务，客户端工具、驱动及云数据库也需同步调整。

必须同时调大服务端和客户端的 max_allowed_packet，只改一端大概率继续报错。

查当前值：别猜，先看实际生效的是多少

执行 SHOW VARIABLES LIKE 'max_allowed_packet'，注意三点：

• 返回值单位是字节（比如 4194304 = 4MB），不是 KB/MB 字符串
• 它显示的是当前会话值，可能被连接池或 ORM 显式覆盖（如 Django 的 OPTIONS['init_command']）
• 真正决定服务端接收上限的是 SELECT @@global.max_allowed_packet，这个才代表 mysqld 进程当前允许的最大包

临时生效：用 SET GLOBAL 或 SET SESSION 快速验证

适合开发环境紧急修复，但重启后丢失：

• 改全局（影响后续所有新连接）：SET GLOBAL max_allowed_packet = 67108864（64MB，必须是整数字节）
• 改当前会话（立刻生效，无需 SUPER 权限）：SET SESSION max_allowed_packet = 134217728（128MB）
• 如果提示 Access denied，说明权限不足，只能走 SESSION 级设置
• 设完立刻再执行 SHOW VARIABLES LIKE 'max_allowed_packet' 确认——MySQL 会向下取整到最接近的 1024 倍数，比如设 67108864 可能变成 67108864，但设 67000000 就会变成 66977792

永久生效：改对配置文件 + 重启 + 验证路径

生产环境唯一可靠方式，但三处容易出错：

• 必须写在 [mysqld] 段下，写在 [client] 或文件开头无效
• 格式要严格：max_allowed_packet = 64M（支持 M/G，64MB、64m、64*1024*1024 都非法）
• 重启不是 reload：sudo systemctl restart mysql（mysqladmin reload 不起作用）
• 不确定配置文件在哪？进 MySQL 执行 SHOW VARIABLES LIKE 'config_file'，它返回的才是真实加载的那个

客户端也得配：命令行、JDBC、pymysql 各有写法

服务端调了，客户端没调，照样卡在本地：

• mysql 命令行启动时加：mysql --max-allowed-packet=64M -u root -p
• pymysql 连接时传参：connect(..., max_allowed_packet=67108864)（单位字节）
• JDBC URL 中加：?maxAllowedPacket=67108864（注意是 camelCase，不是下划线）
• mysqldump 导出时加：mysqldump --max-allowed-packet=128M ...（它的默认值不继承全局配置）
• 云数据库（如阿里云 RDS）通常禁用 SET GLOBAL，得去控制台修改参数组，或升级实例规格

最容易被忽略的是：应用代码里显式设置了低值（比如 HikariCP 的 connection-init-sql 里执行了 SET SESSION max_allowed_packet = 4194304），此时即使服务端和配置文件都调高了，连接一建好就被拉回 4MB。遇到这种情况，得翻应用层配置，而不是反复重试服务端修改。