关闭「每批提交」并启用「手动提交」才能实现单事务大批量写入，否则每批 COMMIT 会拖慢导入；需设「每批记录数」为50000、删SQL文件中的事务控制语句、禁用外键/唯一性检查，并确保UTF-8无BOM编码。
为什么“分批提交”在Navicat里反而拖慢导入？
很多人误以为勾选「每批提交」+调大「每批记录数」就能提速，实际恰恰相反：navicat 的「每批提交」一旦启用，就会在每一批 insert 后执行一次 commit，触发 redo log 刷盘、锁释放、缓冲池刷新——这和逐条提交只有量级差异，没有本质区别。真正要的是**单事务大批量写入**，不是“分批提交”。
必须关闭「每批提交」并启用「手动提交」
这是最常被忽略的硬性开关，不改它，其他优化全无效：
- 打开「运行 SQL 文件」对话框后，务必勾选
手动提交(不自动提交) - 同时取消勾选
每批提交（哪怕你调了 50000，只要它开着，Navicat 就会按该数值反复 COMMIT） - 这个组合让 Navicat 把整个文件（或按其内部切片逻辑）包进一个事务，只在最后发一次
COMMIT
注意：手动提交 不等于“你自己写 BEGIN/COMMIT”——Navicat 会在开头自动发 BEGIN，结尾自动发 COMMIT，外部再套一层事务会导致嵌套失败或降级为单条执行。
调大「每批记录数」到 50000，但仅对纯 INSERT 有效
每批记录数 控制的是 Navicat 向 MySQL 发送 SQL 片段的粒度，不是事务边界。默认 100 或 1000 会引发大量网络往返和解析开销：
- 在
工具 → 选项 → 导入 → 每批记录数中设为50000（Navicat 官方建议上限） - 超过
50000可能触发客户端内存溢出，尤其当某批含长文本、JSON 或 base64 字段时 - 该参数只影响
INSERT INTO ... VALUES (...),(...),...类批量插入；CREATE TABLE、ALTER等 DDL 仍逐条执行，无法合并 - 若 SQL 文件混有
UPDATE、DELETE或存储过程调用，Navicat 会退化为单条执行，此时调大该值无意义
配套必须做的三件事
光调参数不够，以下操作缺一不可：
- 删掉 SQL 文件里的
BEGIN、COMMIT、START TRANSACTION和SET AUTOCOMMIT = 0—— 它们和 Navicat 的手动提交机制冲突 - 导入前执行
SET FOREIGN_KEY_CHECKS = 0;和SET UNIQUE_CHECKS = 0;，导入完再设回1 - 文件编码必须是
UTF-8 without BOM；BOM 头会让 Navicat 解析首行失败，后续全乱，且不报明显错误
真正卡住的地方，往往不是参数没调够，而是 SQL 文件里藏着 Navicat 解析不了的结构：未配对的 DELIMITER $$、跨文件的临时变量、中间插着的 USE database_name; —— 这些不会报错，但会让批量逻辑静默失效。
