navicat同步或导入卡住主因是mysql内部已存在的锁冲突，需优先执行show processlist筛选locked/sending data/waiting for table metadata lock状态进程并kill，再查information_schema.innodb_trx中trx_state为lock wait或trx_started超60秒的长事务并kill对应trx_mysql_thread_id，而非调整隔离级别。
死锁不是navicat的问题，是mysql正在等自己
navicat 本身不制造死锁，它只是暴露了 mysql 内部已存在的锁冲突。你点「同步」或「导入」时卡住，大概率不是 navicat 没反应，而是它发出去的 sql 正在 kill 列表里排队——等着某个没提交的事务释放 mdl 锁或行锁。
先看谁在挡路：用 SHOW PROCESSLIST 找真凶
别急着调隔离级别或重试同步，打开 Navicat 新建查询窗口，直接运行：
SHOW PROCESSLIST;
重点筛这三类状态：
-
Status是Locked、Sending data或Waiting for table metadata lock -
Time超过 60 秒，且Info明显涉及你要操作的表名 -
User和Host不是你当前连接（避免误杀自己）
对符合条件的 ID，逐个执行 KILL 12345（把 12345 换成实际 ID）。这不是暴力，是清场——DDL 和长事务不结束，任何同步都只是往火堆里扔柴。
查不到锁？去 INFORMATION_SCHEMA.INNODB_TRX 看活事务
SHOW PROCESSLIST 只能看到“正在跑”的线程，但一个已开始却没 COMMIT 的事务可能早已静默挂起。运行：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60;
关注这几列：
-
TRX_STATE是lock wait→ 它正卡在等锁，说明上游有阻塞者 -
TRX_STARTED时间异常久 → 很可能是忘记COMMIT或ROLLBACK的开发/测试事务 -
TRX_QUERY显示具体 SQL → 判断是否可安全终止
确认无业务影响后，用 KILL 终止对应 TRX_MYSQL_THREAD_ID，不是 KILL QUERY ——后者只中断语句，事务还活着，锁照常挂着。
Navicat 同步/导入设置里改隔离级别没用
Navicat 同步界面有个「Transaction Isolation Level」下拉菜单，设成 READ COMMITTED 并不能绕过死锁。原因很实在：
- 它只影响同步脚本内部生成的
SELECT/INSERT语句的可见性，对 DDL（如ALTER TABLE）完全无效 -
MDL锁在任何隔离级别下都会被 DDL 强制申请，且与 DML 事务互斥 - Navicat 导入默认每条记录自动提交（
AUTOCOMMIT=1），LOCK TABLES在这种模式下瞬间失效
真正该动的是操作节奏：把「每批提交记录数」从 1000 降到 100，关掉「启用多线程导入」——减少单次锁持有时间，也避免自己跟自己抢锁。
复杂点在于，死锁往往不是孤立事件，而是多个未清理的长事务 + 一次 DDL + 一次导入共同触发的连锁反应。每次卡住，优先查 PROCESSLIST 和 INNODB_TRX，比翻设置快十倍，也更准。
