根本原因是mysqldump启用--extended-insert时单条INSERT打包过多行，超过max_allowed_packet限制；需同时调大服务端[mysqld]段和mysqldump客户端--max-allowed-packet参数（单位大写M），并验证@@global.max_allowed_packet及连接实际协商值。
mysqldump 导入时触发 Packet Too Large 的根本原因
不是数据量大本身出问题，而是 mysqldump 生成的单条 INSERT 语句（尤其启用 --extended-insert 时）打包了过多行，导致整条 SQL 字符串超过 max_allowed_packet 限制。服务端拒绝接收这个“超规包”，直接中断连接，报错形如 Packet for query is too large (8808741 > 4194304)。
为什么只改服务端配置还可能失败
mysqldump 是独立客户端，它不读取服务端的 [mysqld] 配置，也不继承 MySQL 客户端默认值。必须显式传参，否则它按自身内置默认值（常为 4MB 或更低）组装请求包：
-
--max-allowed-packet=512M必须写在mysqldump命令最前面，且单位必须是大写M（写成512m或512MB会失效） - 服务端的
max_allowed_packet也得同步调大，并且必须放在[mysqld]段下，改完要systemctl restart mysql - 如果用的是云数据库（如阿里云 RDS），
SET GLOBAL通常被禁用，只能通过控制台修改参数组
导入前不检查就硬导，容易踩的坑
错误信息里括号中的两个数字很关键：(X > Y) —— X 是实际要发的字节数，Y 是当前生效的上限。但很多人只看 SHOW VARIABLES LIKE 'max_allowed_packet'，结果查的是 session 级变量，被连接池或 ORM 覆盖过，不准。真正该查的是：
-
SELECT @@global.max_allowed_packet;（服务端真实值，单位字节） - 在
mysqlshell 中执行status，看 “max packet allowed” 行——这才是当前连接实际协商到的值 - 导出时若含
BLOB或长文本，建议加--hex-blob；字段含 emoji 就加--default-character-set=utf8mb4
比调大参数更稳妥的绕过方式
不是所有场景都适合无脑拉高 max_allowed_packet。比如内存受限的容器环境，或对延迟敏感的服务，1GB 包反而引发 GC 或网络超时。这时可从源头控制包大小：
- 导出时加
--skip-extended-insert：每行生成独立INSERT，单包体积可控（但文件变大、导入变慢） - 导入前用
split -l 1000 dump.sql chunk_分片，再逐片导入 - 应用层做分批插入（例如 JDBC 批处理设
addBatch()+executeBatch()，每批 500 条以内）
真正容易被忽略的是：服务端和客户端的 max_allowed_packet 是双向协商关系，任何一端卡住，包就发不出去。别只盯着一个地方改。
