必须同时调大服务端和客户端max_allowed_packet，仅改服务端配置无效；Navicat需重连才生效新值，云数据库须提工单修改参数模板并重启，命令行导入须显式指定--max-allowed-packet参数。
不是 MySQL 服务挂了，是连接被主动切断——90% 情况下，max_allowed_packet 太小，根本撑不住你那几万行合在一个 INSERT 里的 SQL 文件。
为什么改了 max_allowed_packet 还报错？
因为这个参数在服务端和客户端**各自独立生效**，只改 MySQL 配置文件，Navicat 自己仍按默认 4MB 收包，照样被拒。
-
max_allowed_packet必须同时覆盖服务端（[mysqld]段）和 Navicat 当前连接（通过变量页或重连新会话） - Navicat 的“服务器监控 → 变量”页修改的是
SET GLOBAL，但旧连接不继承；必须断开再重连才用上新值 - 云数据库（如阿里云 RDS）通常禁用
SET GLOBAL，此时变量页操作无效，只能提工单改参数模板 + 重启 - 某些 MySQL 8.0.23+ 版本对单位更敏感：写成
256m（小写 m）会被忽略，变成 256 字节，比默认值还糟；必须用256M
Navicat 导入时哪些操作会触发这个错误？
它不是随机发生的，而是明确对应两类行为：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- SQL 文件里有超长
INSERT INTO ... VALUES (),(),()...—— 一行含上千条记录，体积轻松突破 4MB - 导入耗时超过
wait_timeout（非交互式）或interactive_timeout（交互式），而 Navicat 默认走交互式路径，但勾选“运行所有查询”后可能降级为非交互，导致实际生效的是wait_timeout - SQL 文件开头带 UTF-8 BOM（
EF BB BF），首行解析失败，后续所有语句偏移，间接引发超时或包校验失败 - Navicat 自身上传缓冲限制：拖入 >100MB 文件时，前端可能先截断或转码失败，错误不体现在 MySQL 日志里
命令行导入也报 ERROR 1153: Got a packet bigger than 'max_allowed_packet' bytes？
这是客户端报的错，说明你只调了服务端，没告诉本地 mysql 工具自己也要放大接收能力。
- 必须显式加参数：
mysql --max-allowed-packet=512M -u root -p db_name - 验证当前客户端限制：
mysql --help | grep "max-allowed-packet"，别只信服务端值 - 如果 SQL 含 emoji 或四字节字符，顺手加上
--default-character-set=utf8mb4，避免编码干扰解析 -
SET GLOBAL max_allowed_packet = ...对已启动的mysql进程无效——它启动时就读完了自己的默认值
真正容易被忽略的是：Navicat 导入过程不显示实时进度，一旦卡住，你不知道是卡在连接、解析、还是执行阶段；建议先导一个最小化测试文件（比如只含 10 行数据的 INSERT），确认配置生效后再跑全量。否则调了半天参数，结果是 SQL 文件本身带 BOM 或跨行注释毁了整个导入流。
