必须同时调大服务端和客户端的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。遇到这种情况，得翻应用层配置，而不是反复重试服务端修改。
