navicat不管理mdl锁，阻塞源于mysql内核；需通过show processlist定位state含“waiting for table metadata lock”的等待者、command为query且info含ddl/dml的持锁者，以及time长的sleep连接，并依次kill等待队列、持锁线程和innodb_trx中running超5分钟的事务。
navicat 本身不管理元数据锁（mdl），所有阻塞都来自 mysql 内核层——你看到的 waiting for table metadata lock 不是 navicat 的 bug，而是它在安静地等 mysql 释放锁；杀错线程、只 kill ddl、忽略隐式事务，都会让问题反复出现。
怎么快速定位谁在 hold MDL 锁？
别依赖 Navicat 界面默认的“活动监视器”全量刷新，它可能漏掉刚挂起的 Sleep 连接。直接进命令行执行：
SHOW PROCESSLIST;
盯三列：State、User、Info：
-
State含Waiting for table metadata lock的，全是等待者，不是源头 -
State是Query或Updating，且Time> 30 秒，Info显示ALTER TABLE/CREATE INDEX/SELECT ... FOR UPDATE的，大概率是持锁者 -
User为navicat或空值，基本可断定是 Navicat 自身发起但未提交的操作（比如点过「保存修改」后关了窗口） - 特别注意
Command是Sleep但State是空、Info为空、且Time很长的连接——这往往是隐式事务没提交，正安静地持有 MDL
为什么只 KILL DDL 线程根本没用？
MySQL 的 MDL 锁绑定在事务上，不是语句上。一个 SELECT 或 UPDATE 开启了事务但没 COMMIT，只要碰过目标表，就可能长期持有写锁。DDL 被 KILL 后，回滚过程本身还要短暂持锁，而所有等待者仍在队列里——等于点了引信，没拆弹。
必须一次性处理整条链：
- 先 KILL 所有
State = 'Waiting for table metadata lock'的会话（清空等待队列） - 再 KILL 那些
State = 'Query'且Info显示 DDL 或长时间 DML 的持锁线程 - 最后查
INFORMATION_SCHEMA.INNODB_TRX，过滤TRX_STATE = 'RUNNING'且TRX_STARTED超 5 分钟的事务，对应 KILL 其TRX_MYSQL_THREAD_ID - 表行数 > 500 万时，KILL 后等 10–20 秒再查
SHOW PROCESSLIST，避免误判锁已释放
如何避免 Navicat 可视化编辑再次触发 MDL 死锁？
Navicat 的「保存修改」按钮本质是拼一条完整 ALTER TABLE 执行，不拆解、不降级、不提示风险——它把最危险的操作当成了最简单的点击。
真正可控的做法是绕过可视化：
- 在 SQL 编辑器里手动拆分：改字段、加索引、改注释，分别写成三条独立语句，逐条执行并确认成功后再继续
- 千万级表的 DDL 必须避开业务高峰，优先用
pt-online-schema-change替代原生操作 - 禁用 Navicat 导入/同步里的「启用多线程」——对同一张表并发写入只会加剧锁竞争
- 同步前手动执行
FLUSH TABLES tbl_name;（替换为实际表名），强制刷新该表元数据缓存，比等自动释放更可靠
最容易被忽略的点：Navicat 界面里看不见那些隐式开启又没提交的 SELECT，它们安静地躺在后台，像一根随时会引爆的引信——查 INNODB_TRX 比盯着 SHOW PROCESSLIST 更早发现隐患。
