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

解决 MySQL 报错“Got a packet bigger than max_allowed_packet”的关键在于，服务端和客户端的 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。遇到此情况，需检查应用层配置，而不是反复重试服务端修改。