直接调大max_allowed_packet是第一动作，因Navicat默认将整个SQL文件当一条语句执行，超默认4MB即被MySQL主动拒收并报ERROR 2006/1153；需SET GLOBAL后重连Navicat才生效，云数据库则须改配置文件并重启。
直接调大 max_allowed_packet 就能解决 90% 的情况，根本不是 MySQL 挂了，而是它主动拒收超长语句。
为什么改 max_allowed_packet 是第一动作
Navicat 导入时默认把整个 SQL 文件当一条语句执行（尤其勾选“运行所有查询”），一旦含大量 INSERT INTO ... VALUES (),(),()... 或 BLOB 字段，单包体积轻松突破默认 4MB 上限。MySQL 不会报“太大”，而是直接断连并抛出 ERROR 2006 或 ERROR 1153。
- 查当前值：
SHOW VARIABLES LIKE 'max_allowed_packet';—— 多数 MySQL 8.0+ 默认是4194304（4MB） - 临时设为 256MB：
SET GLOBAL max_allowed_packet = 268435456;（注意：只对新连接生效） - Navicat 必须断开重连才能用上这个新值，否则仍走旧连接
- 云数据库（如阿里云 RDS）通常禁用
SET GLOBAL，只能走配置文件方案
为什么只改 max_allowed_packet 还可能失败
导入耗时长时，wait_timeout 和 interactive_timeout 也会触发断连。这两个参数控制空闲连接存活时间，默认 28800 秒（8 小时），但部分场景下实际生效的是更短的隐式限制，尤其在非交互式导入中。
- 必须同时调高两个 timeout：
wait_timeout = 28800和interactive_timeout = 28800，值不一致会导致行为不可预测 - 临时生效命令：
SET GLOBAL wait_timeout = 28800;+SET GLOBAL interactive_timeout = 28800;，同样需重连 Navicat - 永久修改要写进
my.cnf或my.ini的[mysqld]段，并带单位后缀：max_allowed_packet = 256M（不能写数字） - 改完必须重启 MySQL：
sudo systemctl restart mysql（Linux）或net stop mysql && net start mysql（Windows）
Navicat 自带变量页修改的坑在哪
Navicat 的 Tools → Server Monitor → Variables 看起来方便，但容易误判：
- 它调用的是
SET GLOBAL，效果等同命令行临时方案，重启 MySQL 后失效 - 部分版本提交后界面不刷新，显示仍是旧值，但实际已生效 —— 别信界面，用
SHOW VARIABLES验证 - 如果 Navicat 连接建立早于修改操作，该连接不会自动更新参数，必须手动断开重连
- 它无法修改客户端侧的
max_allowed_packet，而 Navicat 本身也有独立的接收缓冲区限制（虽极少触发）
还有哪些容易被忽略的硬伤
即使参数全调高，导入仍失败，就要排查更隐蔽的问题：
- SQL 文件含 UTF-8 BOM（
EF BB BF）：MySQL 会把第一行解析成非法语句，后续全错位；用 VS Code 或file -i dump.sql检查，Notepad++ 可转“UTF-8 无 BOM” - Navicat 导入时未关闭自动提交：大事务撑爆内存或锁表，建议先执行
SET autocommit = 0;再导入，或拆成小事务 - 硬切文件用
split -l 10000：会切断跨行INSERT、截断BEGIN...COMMIT块，导致语法错误；安全分片应使用mysqldump --skip-extended-insert导出，或用pt-online-schema-change流式加载 - 客户端和服务端参数未对齐：你改了服务端
max_allowed_packet = 512M，但 Navicat 或命令行没同步，导入仍按客户端默认上限收包
真正卡住的地方往往不在参数数值本身，而在“谁在读、谁在写、谁没重连、谁还带着 BOM”。调参只是起点，验证和隔离才是关键。
