快速定位阻塞SQL需先查INNODB_TRX中TRX_STATE='LOCK WAIT'的事务，再通过INNODB_LOCK_WAITS关联找出BLOCKING_TRX_ID，进而定位阻塞者TRX_QUERY、TRX_STARTED等；SELECT ... FOR UPDATE在RR级别下加临键锁易引发阻塞；长事务通过TRX_START时间差、TRX_STATE及TRX_ROWS_LOCKED等判断；kill前须确认线程来源、是否正在回滚及上游重试逻辑。
如何快速定位正在阻塞的 SQL 语句
锁等待过多，本质是事务没及时释放锁，或者长事务占着资源不放。先看谁在等、谁在挡路，这是最直接的突破口。
在 MySQL 中，information_schema.INNODB_TRX 和 information_schema.INNODB_LOCK_WAITS 是核心入口：
-
INNODB_TRX列出所有活跃事务，重点关注TRX_STATE = 'LOCK WAIT'的行，记下它的TRX_ID和TRX_MYSQL_THREAD_ID - 用这个
TRX_ID去查INNODB_LOCK_WAITS，就能拿到被阻塞的REQUESTING_TRX_ID和阻塞方的BLOCKING_TRX_ID - 再通过
BLOCKING_TRX_ID关联回INNODB_TRX，查出阻塞者的TRX_QUERY（如果还没提交）、TRX_STARTED时间、TRX_WAIT_STARTED等关键字段
注意：TRX_QUERY 可能为 NULL —— 这通常意味着该事务当前没在执行 SQL（比如刚 START TRANSACTION 后就挂起），但锁仍持有。
为什么 SELECT ... FOR UPDATE 也会引发严重锁等待
很多人以为只有 UPDATE/DELETE 才加锁，其实 SELECT ... FOR UPDATE 在可重复读（RR）隔离级别下会加临键锁（Next-Key Lock），不仅锁住匹配行，还锁住“间隙”，极易导致非预期阻塞。
常见踩坑点：
- 没走索引的
FOR UPDATE会升级为表级锁（全表扫描 + 行锁 → 实际效果接近锁表） - 范围查询如
WHERE id > 100，即使有索引，也会锁住满足条件的所有行+间隙，后续插入/更新落在该范围内的记录都会被堵住 - 应用层重试逻辑未设超时，一个慢
FOR UPDATE可能拖垮整条链路
验证方式：执行 SHOW ENGINE INNODB STATUS\G，在 TRANSACTIONS 部分找 lock_mode X locks rec but not gap 或 lock_mode X locks gap before rec，确认锁类型和范围。
如何判断是否是长事务导致锁堆积
长事务本身不慢，但会让已获取的锁迟迟不释放，成为“静默阻塞源”。它往往藏得深，不像慢 SQL 那样容易被监控捕获。
关键指标看 INNODB_TRX 表里的：
-
TRX_STARTED：事务开始时间，和当前时间差超过 60 秒就值得警惕 -
TRX_STATE：如果是RUNNING却长时间无新操作，大概率是应用端没 commit/rollback -
TRX_ROWS_LOCKED和TRX_ROWS_MODIFIED：数值异常高，说明事务已持有大量锁或修改了大量数据
特别注意：某些 ORM（如 Django 的 atomic 块、Spring 的 @Transactional）可能因异常未被捕获，导致事务卡在 open 状态；数据库连接池配置不当（如最大空闲时间 > 应用层超时）也可能让事务“悬停”在连接上。
kill 掉阻塞线程前必须确认的三件事
别一看到 TRX_MYSQL_THREAD_ID 就 KILL，搞错对象可能让问题更糟。
- 先确认该线程对应的是应用真实请求（不是监控探针、备份任务、或 DBA 自己连的调试会话）—— 查
information_schema.PROCESSLIST中的USER、HOST、COMMAND、TIME字段 - 检查它是否已处于
ROLLING BACK状态（PROCESSLIST.COMMAND = 'Sleep'但INNODB_TRX.TRX_STATE = 'ROLLING BACK'），此时 kill 只会让回滚中断，下次重启可能触发更长恢复 - 确认上游是否有重试机制 —— 如果 kill 后应用立即重发相同请求，而根本原因（如缺少索引、逻辑缺陷）没解决，锁等待会立刻重现
真正难的从来不是发现哪个线程该杀，而是弄清它为什么会长时间持锁：是代码漏了 commit？SQL 没走索引？还是业务流程本就不该用事务包这么大的操作？
