Navicat 还原大 SQL 文件卡死的根本原因是其查询编辑器将整文件加载内存并同步语法解析，导致 GUI 主线程阻塞；正确做法是使用“运行SQL文件”功能流式执行，并需预配置忽略错误、避免特殊注释、规范编码与路径。
navicat 还原大体积 sql 文件卡死，根本原因不是网络或磁盘慢，而是它把整份文件加载进内存做语法解析 + 逐条提交事务 —— 一旦文件超 500mb，gui 线程就冻住，连 ctrl+c 都没响应。
为什么双击打开大 SQL 文件必卡
Navicat 的查询编辑器本质是富文本控件，加载时会全量读入内存、同步做语法高亮和语句切分。哪怕你只选中 10 行执行，它仍预解析全文；遇到长 JSON、未闭合引号或嵌套注释，解析器就在某处静默卡住。
- 现象：光标停止闪烁、菜单变灰、任务管理器显示“正在运行”但 CPU 占用低于 15%
- 根源：Win32 GUI 单线程模型下，主线程被阻塞在
recv()或文本渲染，无法处理取消请求 - Navicat 不会告诉你卡在哪一行，只会假死 —— 这不是 bug，是设计限制
必须用「运行 SQL 文件」而非「查询编辑器」
右键数据库 → 运行SQL文件 是唯一能安全处理 GB 级 SQL 的路径。它不加载全文到内存，而是流式读取、分块提交，复用同一个 MySQL session。
- 操作路径：连接 → 右键目标数据库 → 运行SQL文件 → 选择文件 → 勾选「忽略SQL语句错误」（否则单条建表失败就停）
- 注意：
忽略SQL语句错误必须在「工具 → 选项 → SQL 编辑器」里提前勾选，该设置只对当前 session 生效 - 不要勾选「每个文件作为一个事务」——这会让每个文件独立 commit，但大文件本身仍可能因 undo log 撑爆而卡住
SQL 文件内容必须适配批量执行模式
Navicat 的「运行 SQL 文件」对语法容错性远低于命令行 mysql 客户端，尤其反感 MySQL 特有注释和字符集混用。
- 删掉所有
/*!40101 SET */注释，这类指令在批量模式下常被误判为语法错误 - 把文件头的
SET NAMES utf8mb4改成SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs（匹配 MySQL 8.0+ 默认排序规则） - 确保每条语句以分号结尾，且末尾无空格、不可见字符（如 U+200B 零宽空格）
- 避免中文路径 —— Navicat 在 Windows 下对 UTF-8 路径解析不稳定，移到
C:\sql\这类纯 ASCII 路径再试
真正卡住的从来不是屏幕显示，而是 MySQL 网络包大小和服务端解析缓冲区
盯着 Navicat 编辑器调字体或换行，只会浪费时间。最常被忽略的是：Navicat 导入大文件时，它会在后台把整份 SQL 加载进内存再分段执行。如果文件超 500MB，而你的机器只有 8GB 内存，Navicat 自身就可能卡死或崩溃 —— 这时候换 mysql 命令行是唯一靠谱的选择。
