State=Locked不等于真阻塞，因MySQL 8.0+中真实阻塞源常表现为Sleep但trx_state='RUNNING'，需结合INNODB_LOCK_WAITS查BLOCKING_TRX_ID与REQUESTING_TRX_ID定位锁等待链，再通过INNODB_TRX和PROCESSLIST交叉验证线程状态与SQL特征。
只看 SHOW PROCESSLIST 无法确认事务是否真正阻塞，必须结合 INNODB_LOCK_WAITS 才能定位谁在堵谁。
为什么 State=Locked 不等于真阻塞
MySQL 8.0+ 的 PROCESSLIST 中 State 显示 Locked 或 Waiting for table metadata lock，往往只是“等待结果”的表象，不是锁等待链的源头。比如一个 ALTER TABLE 卡在 Waiting for table metadata lock，真正拦住它的可能是一个已运行 12 分钟却没提交的 SELECT 事务——而这个事务在 PROCESSLIST 里 State 是 Sleep，Command 是 Sleep，Info 为空，完全不显眼。
真正可靠的线索是：
-
Command = Query且State长时间停留在updating、deleting、sending data（>30 秒），但 Info 里有UPDATE/DELETE且条件没走索引 -
Time> 60 且Info非空，尤其是含子查询、大范围WHERE或JOIN -
State = Waiting for table metadata lock的线程数量突增，大概率是 MDL 被上游长事务持有了
用 INNODB_LOCK_WAITS 找出真实阻塞关系
INFORMATION_SCHEMA.INNODB_LOCK_WAITS 是唯一能直接告诉你 “谁在等谁” 的视图。它有两列关键字段：BLOCKING_TRX_ID 和 REQUESTING_TRX_ID。只要查到记录，就说明此刻存在真实的 InnoDB 行级锁等待。
执行这三步就能闭环定位：
- 运行
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;—— 若返回空，不代表没阻塞，可能是 MDL 锁或事务还没进入 InnoDB 层 - 用返回的
BLOCKING_TRX_ID去查INFORMATION_SCHEMA.INNODB_TRX，拿到TRX_MYSQL_THREAD_ID - 把这个 ID 去匹配
PROCESSLIST.Id，就能看到阻塞源的完整Info、User、Host
注意：INNODB_TRX 中的 TRX_STATE = RUNNING 表示事务还在干活，TRX_STATE = LOCK WAIT 才表示它自己也被卡住了——别杀错人。
KILL 前必须确认的三件事
盲目 KILL 可能让问题更糟，尤其当锁等待链超过两层时。
- 查
performance_schema.threads确认该线程是否仍在活跃：SELECT THREAD_ID, PROCESSLIST_ID, TYPE FROM performance_schema.threads WHERE PROCESSLIST_ID = <code>xxx; —— 如果TYPE = FOREGROUND且PROCESSLIST_ID非空，说明线程还活着；如果已变成BACKGROUND或查不到，可能已中断但回滚未完成 - 看
PROCESSLIST.Info是否含大范围无索引操作，例如UPDATE orders SET status=1 WHERE created_at —— 这类语句一旦被 KILL，回滚可能持续数分钟 - 确认该线程所属服务模块：定时任务、ETL 脚本、监控探针的 SQL 常有意长时间运行，杀掉可能触发重试风暴或数据丢失
Info 被截断了怎么办
SHOW FULL PROCESSLIST 的 Info 列默认最多显示 1024 字节，再长就砍掉。DDL、带大 JSON 的 INSERT、嵌套 CTE 查询极易被截断，导致看不出实际意图。
更可靠的方式是查 performance_schema.events_statements_current：
- 先确认采集已开启：
SELECT * FROM performance_schema.setup_consumers WHERE NAME = 'events_statements_current';（需为YES） - 再执行：
SELECT THREAD_ID, SQL_TEXT FROM performance_schema.events_statements_current WHERE SQL_TEXT IS NOT NULL ORDER BY TIMER_START DESC LIMIT 5;
这个视图里的 SQL_TEXT 是语句解析后的完整内容，不受 1024 字节限制，但只保留每个线程最近一条执行语句。
真正难处理的从来不是“找不到阻塞源”，而是“找到之后不敢动”——因为那个 Time=328、State=sending data 的线程，可能正回滚着 200 万行的二级索引变更。这时候看 SHOW ENGINE INNODB STATUS\G 里 TRANSACTIONS 部分的 trx_operation_state，比任何 PROCESSLIST 字段都管用。
