根本原因是Navicat 16将大SQL文件全量加载进内存预解析，导致内存耗尽被系统强制终止；应改用mysql命令行流式导入，避免GUI层内存占用。
Navicat 16 执行大 SQL 文件闪退，**不是程序崩溃，而是内存耗尽后被系统强制终止**——尤其在 macOS M1/M2 或 Windows 低内存机器上，根本原因在于它把整个文件加载进进程内存再解析，而非流式处理。
为什么「运行 SQL 文件」会触发 OOM 闪退
navicat 16 的「运行 sql 文件」功能仍沿用旧架构：它会预读全文、构建语法树、校验依赖、缓存元数据，哪怕你只导入纯 insert 数据。一个 300mb 的 .sql 文件，在 electron 或 java 后端（取决于版本）中可能膨胀到 1.5gb+ 内存占用。
- macOS 上闪退常伴随
Terminated due to signal 9 (KILL)或日志里出现memory pressure - Windows 上任务管理器显示
Navicat.exe占用内存飙升后骤降，进程消失 - 即使你勾选了「忽略 SQL 错误」或调小「每批记录数」，这些设置对内存预加载阶段完全无效
为什么改用「新建查询」粘贴执行也不行
很多人尝试把大文件内容复制进「新建查询」窗口再执行，结果仍是卡死或闪退——因为 Navicat 对富文本编辑器的限制比「运行 SQL 文件」更严格：
- 粘贴超过 50MB 文本时，UI 线程直接阻塞在语法高亮渲染阶段，光标冻结，
Ctrl + C无响应 - 它会尝试对整段文本做实时 AST 解析，遇到长字符串、嵌套注释或未闭合引号就卡在某一行
- 即使你删掉所有注释、确保每行以分号结尾，只要文本长度超阈值（实测约 8MB 左右），编辑器底层就会触发保护性退出
真正有效的绕过方式：跳过 Navicat GUI 层
闪退的本质是 GUI 进程扛不住，不是 MySQL 服务端问题。唯一稳定方案是让 SQL 文件不经过 Navicat 内存，直接由 MySQL 客户端流式读取：
- 把
.sql文件放到数据库服务器本地（如/tmp/data.sql），避免网络传输和客户端解析 - 用终端执行：
mysql -u root -p your_db_name （注意是 <code> 重定向，不是 <code>-e） - 若中途报错中断，加
--force参数继续：mysql -u root -p your_db_name --force - Windows 下路径含空格必须用双引号：
mysql -u root -p "test db"
如果必须用 Navicat（比如没服务器 shell 权限）
那就得主动切片、降载、避坑：
- 用
split -l 5000 full.sql part_（Linux/macOS）或 PowerShell 脚本按行拆分，每份控制在 2–5MB - 每份开头加
USE your_db_name;，结尾补COMMIT;（确保事务完整） - 关闭所有其他连接标签页、禁用「查询分析器」和「自动保存历史」
- Windows 用户可尝试修改
navicat.ini中的-Xmx1024m（仅 64 位有效），但上限硬约束明显
