彻底解决 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 可能正好保持原值，但设置 67000000 则会变成 66977792
永久生效：改对配置文件 + 重启 + 验证路径
生产环境唯一可靠的方案，但有三处容易出错：参数必须写在 [mysqld] 段下，写在 [client] 或文件开头均无效；格式要严格：max_allowed_packet = 64M（支持 M/G 后缀，但 64MB、64m、64*1024*1024 都不合法）；重启操作需用 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。遇到此类问题，需要排查应用层配置，而不是反复重试服务端修改。
