根本原因是navicat在内存中全量加载并解析整个sql文件，受java/electron架构堆限制（常低于512mb）制约，导致oom或卡死；而mysql命令行采用流式读取，仅缓存单条语句，内存压力极小。
navicat在windows中导入超大sql文件失败，根本原因不是“文件太大”，而是它在内存里全量加载+解析整个文件——哪怕你有64gb内存，java/electron架构的navicat默认堆限制常卡在512mb以下，一碰到200mb以上的.sql就oom或卡死。直接换命令行是最稳解法。
为什么mysql命令行能过而Navicat挂了
Navicat把整个SQL文件读进内存做语法预检、表名提取、上下文构建；mysql客户端是流式读取，边读边发包给服务端，内存只用在SQL解析和事务缓冲上。
- Navicat报
Out of memory时，错误日志里通常带java.lang.OutOfMemoryError或Electron渲染进程崩溃痕迹 - mysql命令行报错
Packets larger than max_allowed_packet，说明问题在服务端接收层，不是客户端内存 - Windows下路径含空格必须用双引号：
mysql -u root -p testdb - 加
--force参数可跳过单条错误继续执行：mysql -u root -p --force testdb
max_allowed_packet调多大才够用
它限制的是单个网络包大小，不是整个文件。一张表里某几行带base64图片或长日志，一条INSERT拼出来就可能超100MB——所以50MB文件报错、967MB文件却成功很常见。
- 查当前值：
SHOW VARIABLES LIKE '%max_allowed_packet%'，重点看max_allowed_packet（不是slave_max_allowed_packet） - 临时生效（需重连）：
SET GLOBAL max_allowed_packet = 1073741824（1GB），但阿里云RDS等托管库会忽略该命令 - 永久生效：改
my.ini（Windows）或my.cnf（Linux）的[mysqld]段，写max_allowed_packet = 512M（单位必须是M/G，不能写数字） - 改完必须重启MySQL服务，且确认改的是目标实例的配置文件——别误改Navicat自带的客户端
my.ini
文件编码和BOM是静默杀手
Navicat报Unknown command '\ufeff'或第一行全是，基本就是UTF-8 BOM搞的鬼。它把BOM当SQL命令解析，直接崩。
- VS Code右下角看编码，显示
UTF-8 with BOM就点它→选Save with Encoding→UTF-8（明确不含BOM） - Notepad++：菜单「编码」→「转为UTF-8无BOM格式」→保存
- 验证是否干净：
head -n 5 your_file.sql（PowerShell用Get-Content your_file.sql -First 5），正常应看到-- MySQL dump或CREATE DATABASE - 勾选Navicat里的“使用UTF-8编码读取文件”没用——BOM已嵌入字节流，解码前就触发错误
GTID_PURGED语句导致版本不兼容
从MySQL 5.6+导出的备份常含SET @@GLOBAL.GTID_PURGED=...，但目标库若是5.5或已启用GTID的旧实例，这条命令直接报错，且Navicat不会告诉你哪一行。
- 用VS Code或Notepad++打开SQL文件，搜索
GTID_PURGED，整行删掉或注释（加--前缀） - 如果文件超1GB，别用记事本——用VS Code的大文件模式或
sed -i '/GTID_PURGED/d' file.sql（WSL/Linux） - 删完保存，再导入；若仍失败，优先走命令行，别在Navicat里反复试
- 这条语句只影响主从复制初始化，纯数据导入完全不需要
真正卡住人的从来不是参数调多少，而是分不清问题发生在Navicat内存层、MySQL服务端接收层，还是文件本身带了不可见字符——先跑head看开头，再连库查max_allowed_packet，最后才动配置，顺序错了全白忙。
