根本原因在于mysql内核层mdl锁冲突，非navicat问题；需依次kill等待者（state='waiting for table metadata lock'）、持锁者（state='query'且info含ddl/dml、time>30秒）及innodb_trx中trx_state='running'且trx_started超5分钟的事务线程。
Navicat 点「保存修改」报错“无法获取元数据锁”，根本不是 Navicat 的问题，而是 MySQL 内核正在拒绝授予 ALTER TABLE 所需的 MDL（Metadata Lock）写锁——通常因为有其他连接正持有该表的锁，且没释放。
为什么 SHOW PROCESSLIST 里看不到明显阻塞者？
MDL 锁的持有者未必在执行长 SQL；它可能藏在以下三种安静状态中：
-
State为空、Command是Sleep、Time超过 300 秒的连接——这是最常见原因：用户用 Navicat 打开表编辑器后关了窗口，但事务没提交，隐式持有 MDL 写锁 -
State是Query或Updating，Info显示SELECT ... FOR UPDATE、UPDATE或INSERT，且Time> 60 秒——哪怕只是普通 DML，只要开了事务又没 COMMIT，就锁着 MDL -
User是navicat或空值，Info含ALTER、CREATE INDEX等 DDL，但卡在中间没完成——DDL 本身失败或被 KILL 后，回滚阶段仍持锁
KILL 一个线程根本不管用，必须清三类会话
只杀 DDL 线程等于白干：MySQL 的 MDL 锁绑定在事务上，不是语句上。必须按顺序清理整条依赖链：
- 先
KILL所有State = 'Waiting for table metadata lock'的会话（清空等待队列，避免新请求堆积） - 再
KILL那些State = 'Query'且Info含 DDL/DML、Time > 30的持锁线程 - 最后查
INFORMATION_SCHEMA.INNODB_TRX，KILLTRX_STATE = 'RUNNING'且TRX_STARTED超 5 分钟的TRX_MYSQL_THREAD_ID
执行完别急着重试，等 10–20 秒再 SHOW PROCESSLIST 确认无残留锁状态——否则容易误判已释放。
Navicat「保存修改」为什么特别容易触发这个错误？
它把整个表结构变更打包成一条 ALTER TABLE 执行，不拆解、不降级、不提示风险。比如你改字段类型 + 加索引 + 改注释，它生成的是单条语句，内存压力大、锁持有时间长、还容易因 max_allowed_packet 不足直接报 MySQL server has gone away。
- 真正可控的做法是绕过可视化：在 SQL 编辑器里手动写三条独立语句，逐条执行、逐条确认成功后再继续
- 禁用预览功能（
Preferences → DDL → uncheck “Preview DDL before execution”），避免额外查询加重锁竞争 - 修改主键或唯一索引字段时，MySQL 可能降级为
COPY算法，全程锁表——此时哪怕超时调大也没用，必须选低峰期操作
最常被忽略的一点：Navicat 自身发起的操作（比如点过「保存修改」后关了窗口），只要没显式提交或断连，就会以 Sleep 连接形式长期静默持锁——它不会出现在「活动监视器」默认刷新里，必须靠 SHOW PROCESSLIST 手动筛 Time 和 State 才能揪出来。
