Navicat 不解决表级并发修改冲突，因其仅为客户端工具，不参与 MySQL 锁调度；“Waiting for table metadata lock”是 MySQL 内核等待 MDL 释放所致，需通过 SHOW PROCESSLIST 或服务器监控定位并批量终止阻塞会话，防患则依赖变更流程、超时配置及 pt-online-schema-change 等工具。
Navicat 本身不解决表级并发修改冲突
navicat 是客户端工具，它不参与 mysql 的行锁、表锁或元数据锁（mdl）调度。多人同时执行 alter table 或长事务中的 update，冲突是数据库内核行为，不是 navicat 能“避免”的——它只能帮你发现、定位、干预。
为什么你总在 Navicat 里卡住“Waiting for table metadata lock”
这不是网络慢或 Navicat 卡顿，而是 MySQL 正在等一个已持有的元数据锁释放。常见链路如下：
- 同事 A 在 Navicat 执行了
ALTER TABLE orders ADD COLUMN paid_at DATETIME，但没执行完（比如被 Ctrl+C 中断，或卡在磁盘写入） - 此时该会话仍持有
metadata lock，且状态为Waiting for table metadata lock - 你随后在 Navicat 对
orders执行SELECT、INSERT甚至只是双击打开表结构，都会排队等待这个锁
关键点：只要有一个会话卡在 MDL，整张表的读写都会阻塞，且 Navicat 默认不显示这类后台等待——你得主动查。
怎么快速定位并干掉元数据锁源头
别靠猜，用这两招直接命中：
- 打开 Navicat 命令列界面（右键数据库 → “命令列界面”），执行：
SHOW PROCESSLIST;
重点看State列含Waiting for table metadata lock或Locked的行，再看Info列是否是 DDL 语句 - 更省事：Navicat Premium 16+ → 工具 → 服务器监控 → 选择对应实例 → 【死锁进程】标签页
勾选Command = Query且Time > 30秒、State含lock的所有行 → 点【结束进程】
注意：不要只 kill 最上面那个 DDL 进程——MDL 是链式等待，必须把所有 Waiting for table metadata lock 的会话一并清理，否则刚 kill 完，下一个就顶上继续卡。
真正防冲突，得靠流程和配置
工具只能救火，防患靠规则：
- DDL 操作一律走变更工单 + 预发验证，禁止在 Navicat 直连生产库执行
ALTER、DROP - 开发/测试库统一开启
lock_wait_timeout=30（秒），让阻塞操作快速失败，而不是无限挂起 - 大表加索引类操作，用
pt-online-schema-change替代原生ALTER，它能绕过 MDL - Navicat 连接配置里，勾选「自动提交」并关闭「启用查询超时」——后者会导致长时间查询被强制中断，反而更容易留下半截锁
最常被忽略的一点：Navicat 的「活动监视器」默认不刷新死锁视图，你得手动点【刷新】或切换标签页才更新状态；等它自动轮询？可能已经过去五分钟了。
