Navicat中表打不开、编辑按钮灰掉且非权限或网络问题时，大概率是表被锁住；需通过SHOW PROCESSLIST（MySQL）或pg_locks/pg_stat_activity（PostgreSQL）定位阻塞会话，确认后谨慎使用KILL或pg_terminate_backend终止，优先借助Navicat 16+查询分析器识别锁与慢查询共存场景。
表在 navicat 里打不开、点不动、编辑按钮灰掉，不是权限问题也不是网络卡，大概率是锁住了——但 navicat 自己不会告诉你“表被锁定”，只会卡在加载中或显示只读。得自己动手查。
SHOW PROCESSLIST 查不到锁？先看 State 和 Info 字段
MySQL 下执行 SHOW PROCESSLIST; 后，别只扫一眼，重点盯两个字段：
-
State列含Waiting for table metadata lock、Locked、Waiting for table flush—— 这些就是元数据锁或表级锁的明确信号 -
Info列若显示ALTER TABLE、CREATE INDEX、BEGIN后长期没COMMIT，基本就是它堵着 - 注意
Time值：超过 300 秒的Sleep状态，很可能是事务没提交，还在占着锁
pg_terminate_backend 杀错 PID 会丢数据，必须先定位再动手
PostgreSQL 不能靠猜，pg_terminate_backend 的参数必须是整数型 pid，且得确认它真在阻塞你：
- 先查表 OID：
SELECT oid FROM pg_class WHERE relname = 'your_table_name'; - 再查谁锁了它：
SELECT pid, mode FROM pg_locks WHERE relation = <code>oid_from_aboveAND mode LIKE '%Exclusive%'; - 最后查这个
pid在干啥：SELECT pid, state, query FROM pg_stat_activity WHERE pid = <code>target_pid; —— 如果state是active且query是未提交的UPDATE或DELETE，才考虑杀 - 想中断查询而非整个会话，用
pg_cancel_backend；想彻底断开连接，才用pg_terminate_backend
Navicat 自带监控比手敲 SQL 更快定位复合瓶颈
Navicat 16+ 或搭配 Navicat Monitor 时，「查询分析器」能同时叠加显示锁等待 + 执行耗时，比单看 SHOW PROCESSLIST 多一层上下文：
- 它能直接标出哪条慢查询正在等锁，以及谁持有锁
- 对
INNODB_TRX和INNODB_LOCK_WAITS的结果做了可视化聚合，不用手动 JOIN - 特别适合排查“既慢又锁”的场景，比如加索引后 ALTER 卡住，同时导致 SELECT 全部排队
真正麻烦的不是锁本身，而是锁背后那个没提交的事务或没结束的 DDL。杀进程只是临时解法，得回头检查应用代码有没有漏 COMMIT，或者 DBA 是否在业务高峰跑 ALTER TABLE —— 这些才是反复踩坑的根源。
