查表锁用show open tables where in_use > 0；查事务锁用information_schema.innodb_trx和innodb_lock_waits；kill前须确认线程类型与事务状态，避免误杀系统线程或引发长回滚。
查哪些表被锁：用 show open tables 最快最准
直接执行 show open tables where in_use > 0; 就能立刻看到当前被显式锁定（比如 lock tables）或正被写入/ddl 操作占用的表。注意：in_use > 0 表示有活跃引用，不一定是“死锁”，但确实是锁表的起点信号。
-
name_locked列为YES时，说明表名本身被占用了（如正在执行RENAME TABLE或DROP TABLE），此时连SELECT都可能被阻塞 - 该命令对 InnoDB 表的行级锁无效——它只反映表级锁状态，别指望靠它发现长事务导致的行锁等待
- 如果结果为空，不代表没锁；只是没有表级锁，得往下查事务和锁等待
找谁在锁：结合 INFORMATION_SCHEMA.INNODB_TRX 和 SHOW FULL PROCESSLIST
真正卡住业务的，往往是未提交的 InnoDB 事务。先查活跃事务：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX; 关注 trx_state = 'LOCK WAIT' 的行，再用 trx_mysql_thread_id 去匹配 SHOW FULL PROCESSLIST 中的 ID 字段，就能定位到源头 SQL。
-
trx_query可能是NULL（比如事务只做了UPDATE还没提交，后续没发新语句），这时得看trx_started时间和trx_state综合判断是否异常长时间运行 -
SHOW FULL PROCESSLIST的State列显示Locked通常意味着表级锁（MyISAM 或显式LOCK TABLES），而update、sleep状态下仍持有事务锁，容易被忽略 - 别只看
Time大的线程——有些锁等待几秒就超时了，但Time显示才 2 秒，实际已阻塞下游多个请求
看锁等关系：用 INNODB_LOCK_WAITS 定位“谁等谁”
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 是唯一能直接告诉你“哪个事务在等哪个锁”的视图。它返回三列关键 ID：blocking_trx_id、blocked_trx_id、blocking_lock_id，配合 INNODB_TRX 就能串起完整锁链。
- 该视图只在发生锁等待时才有记录，空结果 ≠ 没锁，可能是还没触发等待（比如两个事务刚加锁，尚未尝试冲突操作）
-
blocking_trx_id对应的是INNODB_TRX.trx_id，不是线程 ID；要杀进程，得先用这个trx_id查出trx_mysql_thread_id，再KILL - MySQL 8.0+ 默认关闭
information_schema.innodb_locks（因性能开销），所以别依赖它查“当前持有锁”，专注INNODB_TRX+INNODB_LOCK_WAITS组合
杀还是不杀：KILL 前必须确认事务上下文
执行 KILL <code>thread_id 是最快解法，但风险在于：它会回滚整个事务，如果事务已执行了大量更新，回滚本身可能持续几十秒甚至更久，期间仍持有锁。
- 优先用
KILL QUERY <code>thread_id—— 只中断当前语句，事务保持打开，适合误写的慢查询；但对已进入锁等待的事务无效（它卡在等待，没在执行新语句） - 若
trx_state是LOCK WAIT，说明该事务自己也在等别人，KILL它反而可能释放上游锁，属于“正确止损” - 千万别
KILL系统线程（User为event_scheduler、system user）或主从复制线程（User为replication），会导致复制中断或定时任务失败
锁排查不是拼命令顺序，而是根据现象反推路径：看到接口超时 → 查 INNODB_TRX 找长时间 RUNNING 的事务 → 查 INNODB_LOCK_WAITS 看有没有人在等它 → 再回溯 PROCESSLIST 确认是不是应用端忘了 commit。最容易被跳过的，是那个 trx_state = 'RUNNING' 却已 5 分钟没动静的事务——它不等锁，但它就是锁的源头。
