Navicat加载大SQL文件卡死的根本原因是查询编辑器将整文件同步加载内存并全量解析，导致Win32 GUI主线程阻塞；正确做法是使用“运行SQL文件”功能流式执行，并预配置忽略错误、去除特殊注释、规范编码与路径。
Navicat加载大SQL文件时主线程被全量解析阻塞
Navicat 的「查询编辑器」本质是富文本控件，双击打开或粘贴大 SQL 文件时，会同步读入整个文件到内存，并执行语法高亮、语句切分、上下文构建等操作。哪怕你只打算执行其中 10 行，它仍会尝试预解析全文——遇到长 JSON 字段、未闭合引号、嵌套注释或 U+200B 零宽空格，解析器就在某处静默卡住，UI 光标停止闪烁、菜单变灰、任务管理器显示“正在运行”但 CPU 长期低于 15%。
这不是崩溃，是 Win32 GUI 单线程模型下的设计限制：主线程被阻塞在文本渲染或 recv() 调用上，无法响应 Ctrl+C、右键 Cancel 或任何 UI 事件。
- 现象明确：光标不动、状态栏卡在「Executing」、右键菜单全灰、Ctrl+Enter 无反应
- 和数据库性能无关，重连 MySQL 或换服务器也一样卡
- 200MB 以上文件大概率触发，500MB 基本必卡
- VS Code 或 Notepad++ 打开不卡，说明问题纯属 Navicat 客户端行为
“运行 SQL 文件”才是唯一安全路径
右键数据库 → 运行SQL文件 是 Navicat 中唯一能处理 GB 级 SQL 的入口。它不加载全文进内存，而是流式读取、按块提交（类似命令行），复用同一个 MySQL session，避免 GUI 主线程参与解析。
但这个功能有硬性前提，缺一不可：
- 必须提前在
工具 → 选项 → SQL 编辑器中勾选「忽略SQL语句错误」——否则一条DROP TABLE IF EXISTS报错（表不存在）就中断整个流程 - SQL 文件不能含
/*!40101 SET ... */这类 MySQL 特有注释，它们在批量模式下常被误判为语法错误 - 文件头的
SET NAMES utf8mb4建议改为SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs，匹配 MySQL 8.0+ 默认排序规则 - 路径必须是纯 ASCII（如
C:\sql\dump.sql），中文或空格路径在 Windows 下解析极不稳定
真正卡住的地方从来不是屏幕显示
很多人调字体、关高亮、换主题，试图“让界面快一点”，但卡顿根源根本不在渲染层——而在于 Navicat 在后台把整份 SQL 加载进内存再分段执行。一个 2.73GB 文件，即使你有 64GB 物理内存，Java/Electron 架构的堆限制仍卡在默认 512MB 左右，OutOfMemoryError 日志里必然带 java.lang.OutOfMemoryError 或 Electron 渲染进程崩溃痕迹。
更隐蔽的是服务端配合问题：
-
max_allowed_packet设太小，单条 INSERT 含 base64 图片就超限，MySQL 主动断连，报MySQL server has gone away -
wait_timeout没调高，导入耗时超 8 小时（默认 28800 秒），连接被服务端回收 - SQL 文件自带
BEGIN/COMMIT或SET AUTOCOMMIT = 0，和 Navicat 的「手动提交」模式冲突，导致事务嵌套失败
复杂点和容易被忽略的地方
最常被跳过的动作是验证文件编码：UTF-8 with BOM 会导致第一行出现  或报 Unknown command '\ufeff'，而 Navicat 的「使用UTF-8编码读取文件」选项对此完全无效。必须用 VS Code 右下角切换为「UTF-8（无 BOM）」保存，或用 Notepad++「转为 UTF-8 无 BOM 格式」。
另一个静默杀手是 Navicat 自作主张的会话重置：即使你执行了 SET SESSION sql_mode = ''，只要勾选了「在单独的线程中运行」或新建查询窗口，设置就不继承。所以还原大文件时，务必用「运行 SQL 文件」入口，且取消该线程选项。
