navicat默认导入大型sql文件慢因单条语句提交+语法检查+autocommit=1；关闭语法验证、设autocommit=0并用快速执行可提速3–10倍；超500mb或大量insert时应改用命令行mysql配合--force等参数。
直接用 navicat 的「运行 sql 文件」功能 + 关键参数调整，比默认方式快 3–10 倍；但若脚本超 500mb 或含大量 insert，命令行 mysql 仍是唯一稳解。
为什么默认导入大型 SQL 文件特别慢
Navicat 默认以单条语句为单位提交事务，每执行一条 INSERT 就触发一次磁盘刷写和日志同步；同时 GUI 层会逐行解析语法、校验对象依赖、高亮关键字——这些对小文件无感，但遇到 200MB+ 的初始化脚本时，光加载阶段就卡住几十秒。更糟的是，它默认开启自动提交（autocommit = 1），等于把百万级插入拆成百万次 I/O。
必须关闭的三个选项：语法检查、自动提交、结果返回
在「运行 SQL 文件」窗口中，这三项不关，速度基本无法提升：
- 取消勾选「执行前验证 SQL 语法」：跳过前端解析，交由 MySQL 服务端处理
- 手动在脚本开头加
SET autocommit = 0;，结尾加COMMIT;：把全部操作包进一个事务 - 执行模式选「快速执行(不返回结果集)」：避免 Navicat 缓存和渲染每条语句的结果
注意：SET autocommit = 0 必须写在脚本最前面，且不能被注释包裹；如果原脚本已有 USE database_name;，确保它在 SET 之后、数据语句之前。
当 Navicat 仍卡死或报错时，换 mysql 命令行
这是真正可靠的大容量导入路径，尤其适用于含 CREATE TABLE + 百万级 INSERT 的 dump 文件：
- 先确认连接参数：
mysql -h 127.0.0.1 -P 3306 -u root -p your_db - 追加关键优化参数：
--force --default-character-set=utf8mb4 --max-allowed-packet=512M - 如果脚本开头有
SET NAMES utf8mb4，建议删掉或改为SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs（适配 MySQL 8.0+）
Windows 下若提示乱码，用记事本另存为 UTF-8 无 BOM 格式；macOS/Linux 用 iconv -f GBK -t UTF-8 input.sql > output.sql 转编码。
容易被忽略的编码与分隔符陷阱
Navicat 对文件编码极其敏感，且不报明确错误：
- UTF-8 with BOM 文件大概率触发
Unknown character set: 'utf8mb4'—— 用 VS Code 或 Sublime Text 清除 BOM - 脚本中若含
DELIMITER $$，必须配对出现DELIMITER ;，否则 Navicat 解析到一半就静默终止 - 含中文路径的 .sql 文件，在 Windows 下可能被识别为乱码路径，导致
File not found—— 全部移至英文路径下再试
真正耗时的从来不是“怎么点按钮”，而是确认编码是否干净、事务是否闭合、字符集声明是否匹配服务端实际配置——这三个点没对齐，再调参数也白搭。
