根本原因是索引和约束持续消耗性能：每行插入需同步更新所有索引树、校验外键、写redo log，数据量越大B+树分裂越频繁，磁盘随机写增多，延迟非线性上升；实测从第100万行起单行耗时可翻3倍以上。
为什么导入到一半就明显变卡
根本不是“navicat变慢”，而是索引和约束在持续吃性能。每插入一行，innodb都要同步更新所有索引树、校验外键、写redo log——数据量越大，b+树分裂越频繁，磁盘随机写越多，延迟呈非线性上升。实测从第100万行开始，单行插入耗时可能翻3倍以上。
常见错误现象：INSERT INTO ... VALUES () 语句执行时间从几毫秒涨到200ms以上；Navicat进度条卡住不动超过10秒；MySQL的SHOW PROCESSLIST里看到大量update或insert状态但Time值持续增长。
- 别信“调大批量就能解决”——如果索引还在，批10000条和批100条，单位行开销几乎一样
- 别依赖“快速加载”勾选项——它只跳过部分客户端校验，不关服务端索引维护
- 别在导入中途手动
DROP INDEX——会阻塞正在执行的事务，甚至触发死锁
必须提前删索引，而不是等它变慢再动手
索引删除必须在导入前完成，且要分清主键和普通索引处理方式。主键是聚簇索引，删了会导致表结构失效；非主键索引可安全逐个删，但得记下原始定义，否则重建时字段顺序错一位都可能让查询变慢。
使用场景：目标表已存在，SQL文件只含INSERT（不含CREATE TABLE）。
- 先执行：
ALTER TABLE your_table DROP PRIMARY KEY（仅当引擎是MyISAM或你确认可临时失去主键约束） - 再执行：
ALTER TABLE your_table DROP INDEX idx_created_at、ALTER TABLE your_table DROP INDEX idx_user_id……逐个删 - 导入完成后，用
CREATE INDEX idx_user_id ON your_table (user_id)重建，别用ALTER TABLE ADD INDEX——后者在大数据量下更慢
Navicat“运行SQL文件”的批量参数实际生效条件
批量大小（Batch size）只对纯INSERT语句有效，且前提是SQL文件里没有混入UPDATE、DELETE、存储过程或DELIMITER块。一旦出现这些，Navicat会自动退回到单条执行模式，此时调再大的批量也没用。
参数差异：Batch size = 10000在纯INSERT下能压测出5–8倍提速，但若文件头部有SET AUTOCOMMIT = 0，Navicat反而会忽略该设置，坚持自己控制事务边界。
- 检查SQL文件开头三行：删掉所有
SET、USE、DELIMITER语句 - 编码必须是
UTF-8 without BOM——BOM头会让Navicat把第一行解析成乱码，后续所有INSERT都报语法错 - “忽略错误继续执行”要勾选，否则某一行字段超长或类型不匹配，整个导入就停住
比删索引更稳的替代方案：用SET autocommit = 0包住全脚本
如果你没权限删索引，或表上有强业务约束不能临时放开，这个方法绕过Navicat默认的“每条语句自动提交”机制，把全部INSERT合并成一个事务，减少日志刷盘次数。实测对千万级导入，可稳定提速2–3倍，且不破坏任何表结构。
操作要点很细：必须在Navicat的“新建查询”窗口里手工输入SET autocommit = 0，然后粘贴SQL内容，最后加COMMIT——不能直接“运行SQL文件”，否则SET语句会被忽略。
-
SET autocommit = 0要放在第一行，前面不能有任何空行或注释 - SQL文件里不能自带
COMMIT或START TRANSACTION，否则会冲突 - 导入失败时，记得手动执行
ROLLBACK，否则连接可能卡在未提交状态
LOAD DATA INFILE和SELECT INTO OUTFILE的支持仍受限于secure_file_priv路径，而图形界面里找不到开关。想彻底绕过GUI瓶颈，得切到命令行用mysql -h host -u user -p db_name ——它不走Navicat渲染链路，也不受JVM内存限制。 
