真正卡住数据库的不是SQL本身，而是未提交或挂起的事务；需优先查INNODB_TRX表，关注TRX_STATE（LOCK WAIT或长时间RUNNING）、TRX_STARTED、TRX_QUERY及TRX_MYSQL_THREAD_ID，再结合INNODB_LOCK_WAITS和SHOW PROCESSLIST定位阻塞源头。
查 INNODB_TRX 找出“卡住”的事务
真正卡住数据库的，从来不是某条 SQL 本身，而是它所属的事务没提交、没回滚、甚至只是开了个 BEGIN 就挂在那里。所以第一步必须直奔 INNODB_TRX —— 它是唯一能告诉你“谁还活着、活了多久、在等什么”的实时视图。
TRX_STATE = 'LOCK WAIT' 表示这个事务正在等锁；TRX_STATE = 'RUNNING' 但 TRX_STARTED 时间很早（比如几分钟前），大概率是长事务没结束；TRX_QUERY 字段经常为空——别慌，这不代表没执行 SQL，可能是事务刚 BEGIN 还没发语句，也可能是语句已执行完但事务仍开着。
重点关注 TRX_MYSQL_THREAD_ID，它是后续定位线程和 kill 操作的关键 ID。
用 SHOW PROCESSLIST 匹配线程与真实 SQL
拿到 TRX_MYSQL_THREAD_ID 后，立刻执行 SHOW PROCESSLIST，找 ID 列完全一致的那一行。这才是你实际能操作的入口。
-
Command是Sleep但Time很大（比如 > 60），说明应用拿了连接不释放，事务可能还挂着 -
State是Locked或Updating且Time持续增长，SQL 可能卡在 I/O 或锁等待里 -
Info字段显示的是当前正在执行（或最后执行）的语句，但注意：超长 SQL 会被截断；如果为空，不代表没跑 SQL——有些 ORM（如 PDO 开启ATTR_EMULATE_PREPARES = true）会让真实语句藏在预处理逻辑中
连查 INNODB_LOCK_WAITS 看清锁链关系
单个事务看不出谁堵了谁。INNODB_LOCK_WAITS 是唯一能直接看到“谁在等谁”的视图，它给出的是瞬时锁等待快照，必须在卡顿发生时立刻查，等锁释放了就空了。
典型查询写法：
SELECT r.trx_id AS waiting_trx_id, r.trx_mysql_thread_id AS waiting_thread, r.trx_query AS waiting_query, b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_thread, b.trx_query AS blocking_query FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS w INNER JOIN INFORMATION_SCHEMA.INNODB_TRX b ON b.trx_id = w.blocking_trx_id INNER JOIN INFORMATION_SCHEMA.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;
结果里对比 waiting_query 和 blocking_query，冲突点一目了然：比如一个在更新 user 表主键，另一个在更新同一行的 status 字段。
别忘了 show open tables where in_use > 0 快速扫表级锁
这个命令不看行锁，只看表是否被显式加了表级锁（比如 LOCK TABLES），或者因 DDL 操作（如 ALTER TABLE）隐式阻塞了其他会话。
in_use > 0 表示该表正被使用中，值为 1 通常意味着有活跃事务持有元数据锁（MDL），其他会话对该表的 DDL 或某些 DML 会被阻塞。
它不能替代 INNODB_TRX，但胜在快、无权限依赖、一眼看出哪张表成了瓶颈入口——尤其适合排查“整张表突然不可写”这类问题。
真正难的不是查到锁，而是判断要不要 kill、kill 哪个、以及 kill 之后业务会不会双写或状态不一致。很多线上事故，都出在没看清 TRX_STARTED 时间和 TRX_WAITING_TRX_ID 的因果链，就急着 KILL QUERY 或 KILL 整个线程。
