Navicat导入大SQL文件失败的根本原因是MySQL服务端max_allowed_packet值过小，需修改my.ini（Windows）或my.cnf（Linux/macOS）中[mysqld]段的max_allowed_packet（如设为256M）、wait_timeout和interactive_timeout参数，并重启MySQL服务生效。
直接结论：这不是 navicat 的问题，而是 mysql 服务端拒绝接收过大的 sql 包，核心解法就是调大 max_allowed_packet，且必须让服务端生效——改配置文件 + 重启 mysql 才可靠。
怎么查当前的 max_allowed_packet 值
连上 MySQL 后执行这条命令就能看到实际生效值：
mysql> SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';
返回的 Value 是字节数。比如 4194304 就是 4MB（默认值），对几百 MB 的 SQL 文件完全不够用。
- 注意：只查 session 变量（
SHOW SESSION VARIABLES）没意义，Navicat 导入走的是新连接，用的是 global 值 - 如果用
SET SESSION max_allowed_packet = ...，对 Navicat 导入无效——它不复用你的当前会话 - 某些云数据库（如阿里云 RDS、腾讯云 CDB）不开放
SET GLOBAL权限，此时只能提工单或改控制台参数
永久生效：改 my.ini（Windows）或 my.cnf（Linux/macOS）
找到 MySQL 配置文件，在 [mysqld] 段落下添加或修改这一行：
max_allowed_packet = 256M
常见位置参考：
- Windows：
C:\ProgramData\MySQL\MySQL Server 8.0\my.ini（注意是ProgramData，非Program Files） - Linux：
/etc/my.cnf或/etc/mysql/my.cnf - macOS（Homebrew）：
/usr/local/etc/my.cnf
别只写 256 或 256m——MySQL 只认带单位的写法：256M 或 268435456（字节），小写 m 会被忽略，变成 256 字节，反而更糟。
为什么只用 SET GLOBAL 不推荐
执行 SET GLOBAL max_allowed_packet = 268435456; 确实能立刻生效，但有硬伤：
- MySQL 重启后还原为配置文件里的值（或编译默认值），下次导入照样报错
- 部分 MySQL 版本（尤其是 8.0.23+）要求客户端也同步调整
max_allowed_packet，否则即使服务端调大，Navicat 自身发送时仍可能被截断 - Navicat 16 默认使用较新的连接协议，若服务端
max_allowed_packet和客户端隐含限制不匹配，会出现“导入中途静默失败”——没报错但数据少一半
导入前还要顺手检查的两个配套参数
max_allowed_packet 不是唯一瓶颈。大 SQL 导入常伴随超时，建议一并检查：
-
wait_timeout：空闲连接最大存活秒数，默认 28800（8 小时）。导入卡住或网络抖动时容易触发断连，可设为288000（80 小时）防误杀 -
interactive_timeout：交互式连接超时，默认同wait_timeout，也建议同步调高
这两个参数同样要加进 [mysqld] 段并重启服务才稳定。别指望 Navicat 的“高级连接设置”里调它们——那只是客户端行为，不影响服务端判断是否断开。
真正容易被忽略的是：Navicat 导入大 SQL 时，它会把整个文件读进内存再分段发给 MySQL。如果 max_allowed_packet 设得过大（比如 2G），而服务器物理内存不足，反而可能触发 OOM Killer 杀掉 mysqld 进程。稳妥起见，256M～512M 是多数场景的安全上限。
