必须同时配置服务端和客户端的max_allowed_packet并重启服务，当前值需用SHOW VARIABLES LIKE 'max_allowed_packet'查询，单位为字节；错误信息中括号内左右数值分别表示实际包大小与当前限制。
直接改 max_allowed_packet 就行，但必须同时调服务端和客户端，且单位、位置、重启三者全对——漏一个就白忙。
怎么看当前限制值和实际包大小？
错误信息里括号里的数字最准：Packet for query is too large (8808741 > 4194304)，左边是实际包字节数（约8.4MB），右边是当前限制（4MB）。别信配置文件里写的“64M”——进 MySQL 执行这条 SQL 才真实：
SHOW VARIABLES LIKE 'max_allowed_packet';
返回的 Value 是纯整数，单位永远是字节。4194304 = 4MB，67108864 = 64MB。
为什么只改服务端配置还不行？
还原操作（比如 mysql -u root -p db < dump.sql）本质是客户端行为，它有自己的 max_allowed_packet 默认值（mysql 命令行工具默认仅 16MB）。即使服务端设成 512MB，客户端卡在 16MB 也会报错。
- 临时解决：启动客户端时显式指定，例如
mysql --max_allowed_packet=256M -u root -p db < dump.sql - 永久解决：在
my.cnf的[client]段加max_allowed_packet = 256M，不是[mysqld]段 - 注意：Docker 容器或远程云数据库场景下，你本地改的配置可能根本没生效——先确认连的是哪个实例
还原大文件时容易踩的坑
单纯堆高 max_allowed_packet 只是兜底，不是根治。以下情况即使设到 1GB 也还会失败：
-
dump.sql里含超长单行 INSERT（比如含 20MB JSON 字段），MySQL 不会自动拆分，必须靠客户端缓冲区接住整行 - 使用
mysqldump --skip-extended-insert生成的文件，每条 INSERT 独立成行，但单行仍可能巨大 - Navicat / DBeaver 等 GUI 工具自带网络层和解析逻辑，它们的接收缓冲区可能比 MySQL 客户端更小，此时光调 MySQL 没用
- 备份文件本身有编码或 BOM 头，导致 MySQL 解析时误判长度（少见但真实存在）
真正该优先做的三件事
别一上来就改配置。先做这三步，能避开 70% 的还原失败：
- 用
head -n 100 dump.sql | wc -c和awk '{print length}' dump.sql | sort -nr | head -1查最长行字节数，再留 20% 余量设max_allowed_packet - 还原前加
--force参数（mysql --force -u root -p db < dump.sql），避免某条语句失败导致整个中断 - 对超过 100MB 的 dump 文件，优先用
mysqlimport或分表导入，而不是全库source—— 这类工具内部做了流式处理，不依赖单包大小
最常被忽略的是：max_allowed_packet 是启动时只读参数，改完配置文件后 systemctl reload mysql 不起作用，必须 systemctl restart mysql。而且重启后，所有已建立的连接（包括你的应用连接池）仍沿用旧值，得等它们自然断开或手动清理。
