max_allowed_packet需服务端与客户端同步配置，单位统一为字节；临时set global仅对新连接生效且重启丢失，永久修改须在my.cnf的[mysqld]段写max_allowed_packet = 64m并重启服务；推荐起步值32–64mb，避免盲目设至1g引发oom或复制延迟。
直接改 max_allowed_packet 就行，但必须改对位置、写对格式、重启服务——三者缺一不可。临时 SET GLOBAL 只能救急，不能当永久方案。
怎么确认当前值和单位？
错误信息里括号里的数字（比如 Packet for query is too large (8808741 > 4194304)）左边是实际包大小（字节），右边是当前限制（字节）。执行这条 SQL 最准：
SHOW VARIABLES LIKE 'max_allowed_packet';
返回的 Value 是纯数字，单位是字节。别被“M”“MB”误导——MySQL 配置文件里写 64M 是合法的，但查询结果永远只显示字节数。
临时改：SET GLOBAL 为什么有时不生效？
常见失效场景：
- 没用管理员权限执行
SET GLOBAL max_allowed_packet = 524288000; - 改的是会话级变量（
SET SESSION），不是全局级 - Navicat 连接的不是你本地改的那个 MySQL 实例（比如连了 Docker 容器、云数据库或另一个端口的服务）
- 应用代码里用了连接池，旧连接没断开，新参数对已建立连接无效
临时改只影响后续新建连接，且 MySQL 重启后清零。适合测试或紧急绕过，不适合生产长期依赖。
永久改：my.cnf / my.ini 必须满足这三点
配置文件修改不是“写上就完事”，以下任一条件不满足，等于白改：
- 必须写在
[mysqld]段落内，不能放在[client]或文件开头无段落处 - 格式必须是
max_allowed_packet = 64M（大写 M）或max_allowed_packet = 67108864；64MB、64m、64 * 1024 * 1024全部非法，会导致 MySQL 启动失败 - 必须重启 MySQL 服务才加载——
SIGHUP或RELOAD不起作用，因为这是启动时只读参数
找不到配置文件？别猜路径，进 MySQL 执行：SHOW VARIABLES LIKE 'config_file';，它返回的才是真实加载的那个文件。
改多大才合适？别盲目堆高
max_allowed_packet 不是越大越好：
- 设成 1G 可能导致 OOM，尤其在并发高、内存小的机器上
- 客户端（如 Navicat、Java JDBC）也有自己的接收缓冲区限制，光调服务端没用
- 真正该优化的往往是业务逻辑：大 BLOB 插入、超长 JSON 字段、不分批的 INSERT INTO … VALUES (…), (…), … 都该拆解
建议从 32M 或 64M 起步，观察错误是否消失；再结合实际最大单条语句体积（比如导出的 SQL 文件里最长 INSERT 行长度）留 20% 余量即可。超过 256M 要格外谨慎，先查内存和客户端兼容性。
