该错误实际发生在导入阶段而非导出阶段，根本原因是MySQL服务端对单次接收SQL语句的网络包长度有限制（默认4MB或16MB），当mysqldump生成的含多值INSERT语句超过max_allowed_packet值时，服务端直接拒绝执行并报错1153；必须同步调大服务端[mysqld]和客户端[mysql]段配置，并确保重启生效。
Got a packet bigger than 'max_allowed_packet' bytes 这个错误不是出现在“导出”时，而是**导入时才真正触发**。导出（mysqldump）本身不会受 max_allowed_packet 限制 —— 它只是生成 SQL 文本文件；真正卡住的是后续的「执行导入」动作，比如用 mysql 命令或客户端执行大 INSERT 语句。
关键点在于：MySQL 服务端对**单次接收的数据包大小有硬性上限**，默认通常是 4MB 或 16MB。一旦某条 INSERT 语句（尤其是 INSERT ... VALUES (...),(...),(...) 这种批量写法）生成的 SQL 字符串超过该值，服务端直接拒绝，报错 1153。
为什么 mysqldump 导出的大文件导入会炸？
因为 mysqldump 默认启用 --extended-insert（即多值合并成一行），导出的 SQL 文件里常出现单条 INSERT 包含几千甚至上万行数据。这类语句在解析阶段就被判定为“超长 packet”，根本没机会拆解执行。
- 不是数据总量超限，是「单条语句文本长度」超限
-
max_allowed_packet控制的是网络传输层单次收包上限，不是磁盘或内存总容量 - 服务端和客户端各自维护一份该变量（
[mysqld]和[mysql]配置段），必须两边都调大才稳妥
临时调参后还是报错？检查客户端配置
只改 SET GLOBAL max_allowed_packet = 256*1024*1024 不够——这只是服务端生效。如果你用命令行 mysql -u root -p 导入，客户端（<code>mysql 命令本身）也有自己的 max_allowed_packet 限制，默认可能只有 16MB。
- 查客户端当前值：
mysql --help | grep "max-allowed-packet" - 启动时指定：
mysql --max-allowed-packet=268435456 -u root -p - 或在
~/.my.cnf的[mysql]段加：max_allowed_packet = 256M
不改配置也能绕过？用 --skip-extended-insert
最轻量的解法：重新导出时禁用多值 INSERT，让每行只插一条记录。这样单条语句体积可控，几乎不会触碰 max_allowed_packet 边界。
- 导出命令加参数：
mysqldump --skip-extended-insert -u user -p db_name > dump.sql - 缺点：SQL 文件体积变大（约 3–5 倍），导入速度略慢（IO 多、事务开销略增）
- 优点：零配置变更、无需重启、兼容所有 MySQL 版本
永久生效却没起作用？确认配置文件加载路径和段落
Linux 下 my.cnf 可能有多个位置（/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf、~/.my.cnf），MySQL 只读取第一个存在的。而且 max_allowed_packet 必须放在正确段落下：
- 服务端参数 → 放在
[mysqld]段内 - 客户端参数 → 放在
[mysql]段内（用于mysql命令）或[client]段（通用） - 改完必须重启
mysqld进程（systemctl restart mysql），仅 reload 不生效
