Navicat卡住主因是表锁而非SQL慢，应优先查SHOW PROCESSLIST中Waiting for table metadata lock、长时Sleep及持锁Query，再通过INNODB_TRX定位TRX_STATE为lock wait或RUNNING超5分钟的事务，KILL对应TRX_MYSQL_THREAD_ID而非KILL QUERY。
直接看锁等待链，别只盯“Locked”状态
Navicat 界面里点表没反应、执行 SQL 卡住、导出灰掉——这些不是“慢”，是锁住了。但 SHOW PROCESSLIST 里标着 Locked 的线程往往只是受害者，真凶可能是个 Sleep 连接，或者 State 为空但 Time 超过 300 秒的事务。重点查三类线索：
• State 含 Waiting for table metadata lock 的所有行（等锁者）
• Command 是 Query 且 Info 包含 ALTER TABLE、CREATE INDEX 或带 FOR UPDATE 的 SELECT（持锁者）
• User 是 navicat 或空值、Time > 300、Info 为空的 Sleep 连接（隐式事务未提交）
用 INNODB_TRX 定位真正卡住的事务
SHOW PROCESSLIST 看不到已开始却没提交的“静默事务”。必须查 INFORMATION_SCHEMA.INNODB_TRX：
• 运行 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60;
• 关键字段：TRX_STATE 为 lock wait 表示它在等别人释放锁；TRX_STATE 为 RUNNING 且 TRX_STARTED 超 5 分钟，大概率是开发/测试环境忘 COMMIT 或 ROLLBACK 的残留事务
• 对应的 TRX_MYSQL_THREAD_ID 才是该 KILL 的目标，不是 KILL QUERY —— 后者只中断语句，事务和锁还在
协同排查时，把锁信息固化成可复现的快照
多人协作时口头说“我看到一个 Sleep 连接”毫无意义。每次排查必须留痕：
• 在 Navicat 新建查询窗口，一次性执行三组语句并保存结果：
SHOW PROCESSLIST;
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED DESC LIMIT 5;
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
• 把输出粘贴进共享文档，标注时间戳和执行人
• 若涉及具体表，补一句：SELECT CONCAT('SELECT * FROM ', TABLE_SCHEMA, '.', TABLE_NAME, ' LIMIT 1;') FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'your_table_name'; —— 方便其他人快速验证表是否真被锁死而非权限或只读问题
终止进程前，先确认它不属系统或关键后台任务
KILL 不是按钮，是手术刀。误杀会丢数据或中断备份：
• 永远避开 User 为 system user、event_scheduler、root@localhost（且 Info 为空）的线程
• 在 PostgreSQL / Greenplum 中，pg_terminate_backend() 的参数是整数 pid，不能传字符串；先查 pg_class 得 oid，再用 pg_locks 关联，漏一步就查不到源头
• MySQL 中，KILL 后要等 10–20 秒再跑 SHOW PROCESSLIST —— 尤其表行数 > 500 万时，回滚本身要时间，立刻查可能误判锁已释放
