Navicat 17本身不产生死锁，仅暴露MySQL内部已存在的锁冲突；排查须立即执行SHOW PROCESSLIST筛选Locked/Sending data/Waiting for table metadata lock状态进程并KILL，再查INFORMATION_SCHEMA.INNODB_TRX中TRX_STATE为RUNNING且TRX_STARTED超300秒的长事务并KILL对应TRX_MYSQL_THREAD_ID。
Navicat 17 本身不产生死锁，它只是把 MySQL 内部已存在的锁冲突暴露出来；排查核心不是看 Navicat 日志，而是立刻查 SHOW PROCESSLIST 和 INFORMATION_SCHEMA.INNODB_TRX。
为什么批处理作业一跑就卡在 “Waiting for table metadata lock”
这几乎不是 Navicat 的问题，而是你正在执行的批处理 SQL（比如批量 UPDATE、ALTER TABLE 或带事务的导入）触发了元数据锁（MDL）排队。MySQL 要求所有对同一张表的读写操作必须串行获取 MDL，一旦某个会话持锁时间过长（例如未提交事务、大 DDL、磁盘 I/O 卡顿），后续所有操作都会挂起等待。
- Navicat 17 的批处理默认开启
AUTOCOMMIT=1，但如果你手动写了BEGIN或勾选了「使用事务」，那整个批处理就变成单个长事务——锁会一直持有到COMMIT或连接断开 - 常见诱因包括：开发环境留着未提交的
SELECT ... FOR UPDATE、测试脚本崩溃后连接没释放、或另一台机器正用 Navicat 对同一张表点「保存修改」（本质是隐式ALTER TABLE） -
SHOW PROCESSLIST中看到多个Status为Waiting for table metadata lock的线程，说明等待队列已形成，此时只 kill 最上面那个没用
快速定位持锁者和幽灵事务的两条命令
别依赖 Navicat 17 的「活动监视器」图形界面——它刷新有延迟，且可能过滤掉 Command = Sleep 但实际仍持有锁的连接。直接在新查询窗口执行：
SHOW PROCESSLIST;
重点筛三类：
- Status 含 Locked、Sending data 或 Waiting for table metadata lock
- Time > 60 秒，且 Info 明显涉及你要操作的表名（如 UPDATE orders SET ...）
- User 是 navicat、dev_user 或为空值（大概率是你自己没关的会话）
再补一刀查隐式事务：
SELECT TRX_ID, TRX_STATE, TRX_STARTED, TRX_QUERY, TRX_MYSQL_THREAD_ID FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 300;
重点关注：
- TRX_STATE = 'RUNNING' 且 TRX_STARTED 超 5 分钟 → 很可能是忘记 COMMIT 的批处理残留
- TRX_QUERY 是 UPDATE/DELETE 但没结束 → 直接对应 KILL TRX_MYSQL_THREAD_ID（不是 KILL QUERY）
Navicat 17 批处理设置里哪些选项会加剧死锁
批处理界面右下角的「高级」设置看似能优化性能，实则容易埋雷：
- 「每批提交记录数」设为 10000 → 单次事务锁表时间拉长，增大与其他操作冲突概率；建议压到 100–500，尤其对大表
- 「启用多线程导入」勾选 → 多个线程并发写同一张表，自己跟自己抢 MDL 锁，反而比单线程更容易卡住
- 「事务隔离级别」改成
READ COMMITTED→ 完全无效：MDL 锁与隔离级别无关，DDL 操作在任何级别下都强制申请排他锁 - 「启用外键检查」或「启用唯一性检查」→ 在大批量插入时会额外增加锁检测开销，非必要可临时关闭
KILL 之后为什么还是卡？关键收尾动作被忽略
很多人 kill 完就点重试，结果几秒后又卡住——因为 MySQL 的 MDL 锁清理不是即时的，尤其源库刚重启过或磁盘慢时：
- 执行完所有
KILL后，务必等 10–15 秒再查SHOW PROCESSLIST，避免误判“已清空” - 如果卡在
Waiting for table metadata lock且SHOW PROCESSLIST看不到明显持锁者，立即执行：FLUSH TABLES tbl_name;（把tbl_name替换为实际表名）→ 强制重载该表元数据，清掉残留 MDL 引用 - 若权限允许，更彻底的做法是：
FLUSH TABLES WITH READ LOCK;→UNLOCK TABLES;（注意：此操作需SUPER权限，且会短暂阻塞写入） - 最后验证：
SHOW OPEN TABLES WHERE In_use > 0;返回空结果才算真正释放
真正难处理的从来不是“怎么 kill”，而是“kill 哪些”和“kill 之后要不要等”。MDL 锁不像行锁会随事务结束自动释放，它可能卡在内核调度、磁盘刷盘或网络中断恢复阶段——盯住 TRX_STARTED 时间戳和 SHOW PROCESSLIST 的 Time 列，比看 Navicat 界面转圈可靠得多。
