Waiting for table metadata lock 的根源是未提交事务持有MDL锁，需通过performance_schema.metadata_locks查LOCK_STATUS='GRANTED'的持锁线程，重点排查Command='Sleep'且INNODB_TRX中trx_state='RUNNING'的悬挂事务，严禁只KILL等待DDL线程。
navicat 16 可视化编辑表结构（比如加字段、改类型）时卡住不动，或报 waiting for table metadata lock，根本不是“操作太慢”，而是 mysql 的元数据锁（mdl）被阻塞后，navicat 仍在傻等——它不会自动识别并终止等待链。
怎么快速定位哪个会话在死锁元数据？
Navicat 自带的「活动监视器」在 Premium 16+ 版本里能直接筛出问题连接，但前提是你要知道看哪几列：
- 打开工具 → 服务器监控 → 选择对应 MySQL 实例 → 切到【死锁进程】标签页
- 重点筛选：
Command为Query、Time> 30 秒、State含metadata lock或Waiting for table metadata lock - 别碰
Command是Sleep的行——那是正常空闲连接，杀错会导致业务断连 - 如果没看到明显异常，右键数据库 → 命令列界面 → 手动执行
SHOW PROCESSLIST;，盯紧State和Info列，后者常显示卡住的ALTER TABLE语句
为什么只 KILL DDL 语句本身没用？
MySQL 的 MDL 是事务级的，不是语句级的。一个未提交的 SELECT 或 UPDATE 事务只要碰过这张表，就可能持有 MDL；DDL 被 KILL 后，回滚过程本身还会短暂持锁，而所有排队的会话还在等——等于清了火药桶引信，但没拆弹。
- 必须一次性 KILL 所有
State为Waiting for table metadata lock的会话，清空整个等待队列 - 特别注意
User是navicat或为空的连接，大概率是 Navicat 自身发起的未提交操作（比如你点过「保存修改」但中途关了窗口） - DDL 被 kill 后，若表行数 > 500 万，建议等 10–20 秒再查
SHOW PROCESSLIST，避免误判“已释放”
如何避免可视化编辑再次触发元数据锁死？
Navicat 的「保存修改」按钮本质是拼一条完整 ALTER TABLE 执行，不拆解、不降级、不提示锁风险——它把最危险的操作当成了最简单的点击。
- 关闭预览：Preferences → DDL → 取消勾选
Preview DDL before execution（否则会先跑SELECT COUNT(*)，这个查询自己就会被锁阻塞） - 拆分操作：同时改字段 + 加索引 + 改注释？手动拆成 3 条独立语句，在 SQL 编辑器里逐条执行
- 避开 COPY 算法：改主键或唯一索引字段时，MySQL 很可能降级为全表拷贝，全程锁表。这种操作别用可视化，改用命令行 +
ALGORITHM=INPLACE显式控制 - 高峰期绕开：千万级表的 DDL，哪怕设了 30 分钟
Socket Timeout，也扛不住磁盘 I/O 峰值带来的锁等待雪崩
真正麻烦的从来不是“怎么 kill”，而是“谁在 hold 锁却没显式事务”。Navicat 界面里看不见那些隐式开启又没提交的 SELECT，它们安静地躺在后台，像一根随时会引爆的引信。
