根本原因是Navicat在内存中一次性加载并解析整个SQL文件，导致Java或Electron架构内存不足；应改用mysql命令行导入，由MySQL服务端直接流式读取，大幅降低内存占用。
Navicat 导入大 SQL 文件直接报 Out of memory
根本原因不是 sql 本身写错了，而是 navicat 在内存中一次性加载并解析整个文件——哪怕只是个 100mb 的 .sql，它也会尝试构建成完整的执行上下文。java 后端（部分版本）或 electron 架构的内存模型扛不住这种压力，尤其在 windows 上默认堆限制常卡在 512mb 以下。
这时候别折腾“运行 SQL 文件”对话框里的勾选项，那些对内存占用几乎没影响。
改用 mysql 命令行导入（推荐首选）
绕过 Navicat 的 UI 层，让 MySQL 服务端直接读取文件流，内存只用于 SQL 解析和事务缓冲，不涉及 GUI 渲染或结果集缓存。
mysql -u root -p database_name —— 注意是重定向，不是-e- 如果提示
max_allowed_packet超限，先连进去执行：SET GLOBAL max_allowed_packet = 1073741824;（即 1G），再退出重试 - Windows 下路径含空格要用双引号包裹：
mysql -u root -p testdb - 导入中途失败？加
--force参数跳过单条错误继续，避免全盘中断
降低 Navicat 自身内存压力的实操项
不是所有场景都能切命令行（比如你没服务器 shell 权限，或用的是 PostgreSQL/SQL Server）。这时可动几个关键开关：
- 关闭所有未使用的连接标签页和查询窗口——每个打开的标签都维持独立连接会话，吃内存
- 右键数据库连接 → “连接属性” → “高级” → 把
Fetch Size改成100或500（默认可能是0表示全取） - 禁用“自动保存查询历史”和“启用查询分析器”，这两项在大数据导入时会偷偷缓存 AST 和执行计划
- 若用的是旧版 Navicat（v15 及之前），检查安装目录下
navicat.ini，把-Xmx512m改成-Xmx1024m，但注意：64 位系统才有效，32 位上限仍是 ~1.5GB
拆分 SQL 文件比调参数更可靠
很多用户卡在“为什么我调了 max_allowed_packet 还是挂”，其实问题不在传输层，而在 Navicat 解析阶段——它会预扫描 INSERT 语句、提取表名、校验语法，这个过程无法跳过。
真正稳的做法是提前切片：
- 用
split -l 5000 full_dump.sql part_（Linux/macOS）按行切，每份约 5000 条 INSERT - Windows 可用 PowerShell：
Get-Content large.sql -ReadCount 5000 | ForEach-Object { $i++; $_ | Set-Content "part_$i.sql" } - 确保每份以
USE db_name;开头，并在末尾补上COMMIT;（如果原文件没显式事务） - 然后在 Navicat 中逐个“运行 SQL 文件”，而不是一股脑拖进去
拆分看似麻烦，但比反复重启 Navicat、等进度条卡死再重来快得多；而且你能清楚看到哪一批出错，定位问题语句也直观。
