结论是navicat导入失败主因并非软件缺陷，而是撞上数据库中未提交的长事务（如update/alter table）、磁盘空间不足或并发工具阻塞；应优先通过innodb_trx和processlist定位并kill隐患线程，而非调整navicat参数。
直接说结论：这不是 navicat 的 bug，而是它撞上了数据库里正在运行的“钉子户事务”——比如一个没提交的 update、卡住的 alter table，或者磁盘空间已满导致临时表写不进去。修复重点不在调 navicat 设置，而在快速定位并清理冲突源头。
查哪些事务在“赖着不走”
Navicat 导入失败时，先别急着改超时时间或重试。打开新查询窗口，运行：
SELECT TRX_ID, TRX_STATE, TRX_STARTED, TRX_QUERY FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 10;
重点关注 TRX_STATE = 'RUNNING' 且 TRX_STARTED 时间超过 5 分钟的记录；如果 TRX_QUERY 是 UPDATE 或 DELETE 但没 COMMIT，这就是罪魁祸首。
- 配合
SHOW PROCESSLIST，筛出Status是Locked、Updating或Time > 300的线程 - 特别注意
User字段是否为开发/测试账号（如'dev_user'），这类线程往往来自调试中的 IDEA 或未关闭的脚本 - 如果看到
Command = 'Sleep'但Time很大，说明连接空闲但事务没结束，不能只KILL QUERY，必须用KILL [ID]
为什么 LOCK TABLES 在 Navicat 导入里基本没用
LOCK TABLES table_name WRITE 看起来很直接，但在 Navicat 导入场景下几乎无效：
- Navicat 导入默认开启
AUTOCOMMIT=1，每条INSERT都是独立事务，LOCK TABLES拿到的锁在第一条插入后就自动释放 - 你执行
LOCK TABLES后，Navicat 自己立刻尝试写入，触发「当前连接不能更新自己加了 READ 锁的表」错误，报Table 'xxx' was locked with a READ lock and can't be updated - InnoDB 的行级锁机制和
LOCK TABLES的表级语义天然冲突，尤其在READ-COMMITTED或更高隔离级别下，锁行为不可控
导入前必须检查的三类“隐形阻塞源”
很多死锁不是导入引起的，是导入“踩雷”了。以下三类情况必须手动确认：
-
磁盘空间不足：执行
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE INFO LIKE '%#sql%';，若返回结果含/mysql/tmp/#sql...且提示The table is full，立刻清理 Linux/var/lib/mysql所在分区 -
长 DDL 正在执行：运行
SHOW FULL PROCESSLIST;，查找Command = 'Query'且Info包含ALTER TABLE、CREATE INDEX的线程——旧版 MySQL 中这类操作会全表锁，Navicat 导入必然卡住 -
其他工具正在连表操作：比如 IDEA 正在调试一段往同一张表批量
INSERT的代码，或另一个 Navicat 窗口开着未提交的事务。关掉所有非必要连接再试
导入设置里真正有用的两个参数
如果确认无外部阻塞，再调整 Navicat 导入行为本身：
- 把「每批提交记录数」从默认 1000 改为
100或50：缩短单次事务持有行锁的时间，降低与其他事务交叉等待概率 - 务必关闭「启用多线程导入」：多线程对同一张表并发
INSERT，等于主动制造锁竞争，InnoDB 行锁升级成间隙锁后极易形成死锁环 - 不要碰
innodb_lock_wait_timeout全局值——临时改 Session 级别（如SET SESSION innodb_lock_wait_timeout = 3600;）可以应急，但掩盖问题，下次还会爆
真正难处理的，是那些没显式事务却长期占用锁的场景：比如应用层用了连接池但没正确 close()，或者 ORM 自动生成的 UPDATE 语句没带 WHERE 条件导致全表扫描加锁。这种得靠 SHOW ENGINE INNODB STATUS\G 里的 LATEST DETECTED DEADLOCK 区块反查 SQL 原始来源。
