错误信息“Packet for query is too large (8808741 > 4194304)”中，左边8808741是实际语句字节数（约8.4MB），右边4194304是当前生效的max_allowed_packet值（4MB）；真实值须通过SHOW VARIABLES LIKE 'max_allowed_packet'确认，单位恒为字节。
怎么看错误信息里的真实包大小和当前限制？
错误信息 Packet for query is too large (8808741 > 4194304) 括号里两个数字就是关键：左边 8808741 是实际语句字节数（约 8.4MB），右边 4194304 是当前生效的 max_allowed_packet 值（4MB）。别信配置文件里写的“64M”——进 MySQL 执行 SHOW VARIABLES LIKE 'max_allowed_packet'，返回的 Value 才是真实值，单位永远是字节。
为什么改了服务端配置还是报错？
因为还原或插入操作本质是客户端行为，它有自己的缓冲区限制：
-
mysql命令行工具默认只认16MB，哪怕服务端设成512MB，它仍会在16MB处截断 - Navicat、DBeaver 等 GUI 工具自带网络层，它们的接收缓冲区可能比 MySQL 客户端还小
- Java 应用用 JDBC 连接时，
max_allowed_packet不是驱动自动继承的，得在连接 URL 里显式加参数，比如?maxAllowedPacket=268435456
怎么临时绕过、快速验证是否真由包大小引起？
先不改配置，用最小成本确认问题根源：
- 用
head -n 100 dump.sql | wc -c和awk '{print length}' dump.sql | sort -nr | head -1查出最长单行长度，再留 20% 余量设目标值 - 还原时加
--force参数：mysql --max_allowed_packet=256M --force -u root -p db ，避免某条语句失败就中断 - 对超大文件（>100MB），直接放弃
source或重定向，改用mysqlimport或分表导入——这些工具内部流式处理，不依赖单包大小
永久修改配置最容易踩的三个坑
改 my.cnf 不是写上就完事：
- 服务端必须写在
[mysqld]段，客户端参数（如命令行工具）要写在[client]或[mysql]段，写错段落等于没改 - 格式必须是
max_allowed_packet = 64M（大写 M）或max_allowed_packet = 67108864；写成64MB、64m、64 * 1024 * 1024全部非法，MySQL 启动会失败 - 改完必须重启服务：
systemctl restart mysqld（Linux）或 Windows 服务管理器重启，SIGHUP或RELOAD不起作用
真正容易被忽略的是：你本地改的配置，连的未必是你以为的那个实例——Docker 容器、云数据库、多实例共存时，先用 SHOW VARIABLES LIKE 'config_file' 确认 MySQL 加载的是哪个文件，再动手改。
