根本原因是单次网络包超限，而非sql文件体积大；错误源于insert/update含超长字段、mysqldump返回大blob行、source执行巨长语句或load data单行数据超过max_allowed_packet限制。
这不是文件太大，是单次网络包超限
MySQL 报 Packets larger than max_allowed_packet are not allowed 或 Got a packet bigger than 'max_allowed_packet' bytes，根本原因不是“SQL 文件体积大”，而是某一次网络传输中，MySQL 客户端或服务端试图收发一个超过 max_allowed_packet 限制的单个数据包。这个包可能是：
- 一条含超长 JSON / Base64 / TEXT 字段的
INSERT或UPDATE语句 - mysqldump 导出时，服务端返回的一行带大 BLOB 的结果
- 客户端用
source执行的某条巨长INSERT ... VALUES (...),(...),...（含上万组值） - LOAD DATA 读取的单行原始数据
一旦实际包大小（比如 8.4MB）超过当前生效的 max_allowed_packet 值（比如默认 4MB），MySQL 就会立刻断开连接，不重试、不提示具体哪条语句——所以你看到的往往是 “MySQL server has gone away” 这类模糊错误。
查清楚到底是哪边卡住了
服务端和客户端各自维护一套 max_allowed_packet，必须分开确认：
- 查服务端当前全局值：
SHOW VARIABLES LIKE 'max_allowed_packet';（返回的是mysqld进程加载的值） - 查当前客户端会话值：
SHOW SESSION VARIABLES LIKE 'max_allowed_packet';（在 mysql 命令行里执行，反映的是该连接实际能用的上限） - 如果你用 Navicat、DBeaver、SQLyog 等图形工具，它们不读
my.cnf，得进连接设置里手动填或连上后执行SET SESSION max_allowed_packet = 268435456; - 云数据库（如阿里云 RDS）通常禁止
SET GLOBAL，需走控制台参数组修改
mysql 命令行导入时 --max-allowed-packet 不生效？位置和单位错了
用 mysql db_name 方式导入，<code>--max_allowed_packet 参数必须放在命令最前面，且单位只能是 M（大写），不能是 MB 或 m：
- ✅ 正确：
mysql --max_allowed_packet=256M -u root -p db_name - ❌ 错误：
mysql -u root -p --max_allowed_packet=256MB db_name （位置错 + 单位错） - ❌ 错误：
mysql --max_allowed_packet=268435456 -u root -p db_name （虽合法但易输错，不推荐）
如果改用交互式 source 导入，必须先在 mysql shell 里执行：SET SESSION max_allowed_packet = 268435456;，再 source dump.sql —— 否则照样在第一条大语句就失败。
别漏掉 net_buffer_length 和 timeout 连带影响
即使 max_allowed_packet 调高了，还有两个隐藏坑：
-
net_buffer_length：默认仅 16KB，影响 INSERT 多值语句的内部分包逻辑。大语句可能被错误拆包，导致解析失败。建议同步设为1048576（1MB），只对当前会话有效：SET SESSION net_buffer_length = 1048576; -
wait_timeout/interactive_timeout：大数据导入耗时长，超时会直接断连。配置文件中需一并加上（单位秒）：wait_timeout = 28800、interactive_timeout = 28800，改完重启服务 - JDBC、pymysql 等应用层驱动也有自己的
max_allowed_packet参数，必须单独配，不能指望服务端设置自动透传
真正麻烦的从来不是调数字，而是服务端、客户端、应用连接池、SQL 结构四者没对齐——哪怕只有一处卡在 4MB，整个导入就停在第一行。
