“运行sql文件”更稳因流式读取、不全载内存、复用会话；双击或粘贴走查询编辑器会全量加载并预解析全文，导致gui主线程卡死。
为什么“运行sql文件”比粘贴执行更稳
双击打开或粘贴进查询编辑器执行大 sql，navicat 会把整个文件读进内存做语法高亮和语句切分——哪怕你只选中 10 行，它仍预解析全文。win32 gui 主线程卡在文本渲染或 recv() 上，光标停转、菜单变灰、ctrl+c 失效，根本不是 sql 错了，是 ui 层扛不住。
真正该走的路径是：右键数据库 → 运行SQL文件。它不加载全文，而是按行/按语句块流式读取，复用同一个 MySQL session，支持跨语句变量（如 @start）和事务控制。
- 必须提前在
工具 → 选项 → SQL 编辑器中勾选「忽略SQL语句错误」，否则单条建表失败就中断 - 别勾「每个文件作为一个事务」——大文件本身可能因 undo log 撑爆而卡住
- 文件路径避免中文或空格，Windows 下建议移到
C:\sql\这类纯 ASCII 路径
MySQL 服务端参数不调，客户端再怎么优化也白搭
Navicat 走对了「运行SQL文件」路径，但 max_allowed_packet 太小，MySQL 服务端一收到超长 INSERT 就断连，表现就是“卡几秒后无声退出”。这不是 Navicat 的错，是服务端拒绝接收。
修改 my.ini（Windows）或 my.cnf（Linux），关键项必须生效并重启 MySQL：
-
max_allowed_packet=1024M：决定单条 SQL 或数据包上限，SET GLOBAL临时改只对当前连接有效，重启后失效 -
innodb_buffer_pool_size=16G：占物理内存 1/4～1/2，64GB 机器设 16G 合理；设太大反而触发 OS OOM killer -
innodb_log_file_size=1024M：需先mysqld --shutdown再删旧 ib_logfile* 才能生效 -
innodb_flush_log_at_trx_commit=2：导入期间允许少量日志延迟落盘，提速明显
Navicat 自身内存配置要动真格
Navicat 底层部分版本用 Java，navicat.ini 里默认 -Xmx512m 在处理含 TEXT/BLOB 的千万级表时完全不够。改完不重启等于没改。
- 找到配置文件：
C:\Program Files\PremiumSoft\Navicat Premium\navicat.ini（Windows）或/Applications/Navicat Premium.app/Contents/Resources/navicat.ini（macOS） - 把
-Xmx512m改成-Xmx1024m或-Xmx2048m（不超过物理内存 1/2） - 同步设置
-Xms256m，避免频繁 GC 拖慢节奏 - 改完保存，必须彻底杀掉所有 navicat.exe 进程（任务管理器里看有没有残留）再重启
拆文件比调参数更可靠
很多用户折腾半天 max_allowed_packet 还是挂，问题不在传输层，而在 Navicat 解析阶段——它会预扫描所有 INSERT、提取表名、校验语法，这个过程无法跳过。拆分是唯一稳解。
- Linux/macOS：
split -l 5000 full_dump.sql part_，每份约 5000 条 INSERT - Windows PowerShell：
Get-Content large.sql -ReadCount 5000 | ForEach-Object { $i++; $_ | Set-Content "part_$i.sql" } - 确保每份开头有
USE db_name;，末尾补COMMIT;（如果原文件没显式事务） - 导入时逐个用「运行SQL文件」执行，勾选「忽略SQL语句错误」+「快速执行(不返回结果集)」
真正容易被忽略的是：Navicat 的「运行SQL文件」对 MySQL 特有注释极其敏感，比如 /*!40101 SET ... */ 必须删掉，否则静默卡在解析阶段——它不像命令行 mysql 客户端那样兼容。
