MySQL 8 锁等待：先分清取证视图
从有道云笔记提炼的诊断线索。源笔记是一份通用指南，没有可核验的事故记录；本页未在具体实例上验证，也不构成生产处置步骤。
适用边界
面向 MySQL 8.0 的 InnoDB 数据锁、表元数据锁和死锁调查。使用前核对具体小版本、sys 与 Performance Schema 视图是否可用，以及查询权限；其他版本或兼容产品不能直接套用。8.0 中不应沿用旧的 INFORMATION_SCHEMA.INNODB_LOCKS / INNODB_LOCK_WAITS 查询思路。
先按现象选证据
| 要回答的问题 | 候选只读视图或命令 | 证据边界 |
|---|---|---|
| 此刻哪些 InnoDB 事务互相等待？ | sys.innodb_lock_waits；需要底层关系时看 performance_schema.data_lock_waits | 反映查询时刻的等待关系；结果为空不能证明没有持锁事务，也不能排除稍早发生的等待。 |
| 哪些数据锁已获授或正在等待？ | performance_schema.data_locks | LOCK_STATUS 区分 GRANTED 与 WAITING；LOCK_TYPE=TABLE 还可能是意向锁，不能单凭字段断定整表被业务操作锁住。 |
| DDL 是否在等表元数据锁？ | sys.schema_table_lock_waits，辅以连接状态 | 将等待会话、阻塞会话和对象对应起来；DDL 卡住只是调查入口，原因仍需证据确认。 |
| 阻塞会话当前没有 SQL，事务是否还在？ | information_schema.innodb_trx，辅以 SHOW FULL PROCESSLIST | trx_query 为空不代表事务已提交；核对事务开始时间、连接和业务归属。 |
| 已消失的等待是否涉及死锁？ | SHOW ENGINE INNODB STATUS 中最近一次死锁信息 | 只提供有限历史窗口，不能证明所有过去的死锁。 |
事实、假设与处置
视图中实际出现的等待方、阻塞方、事务和时间是待留存的观察；“长事务导致阻塞”“缺少索引导致锁范围扩大”只是需要继续核查的假设。取证时记下采样时间、数据库版本、会话与事务的对应关系，并将 SQL 文本、账号和对象名从共享记录中脱敏。
终止语句或连接属于处置，不能从一条等待关系直接推出。尤其只终止当前语句时，未提交事务可能仍持锁；终止连接也可能触发较长时间的回滚。进入处置前，使用 阻塞事务处置草稿 核对业务影响、目标归属和授权。
待核查
- 在目标 MySQL 小版本上确认视图字段、权限、采集开销及元数据锁观测是否可用。
- 用可控演练分别验证数据锁等待、元数据锁等待和空闲未提交事务的证据差异。
- 若要形成可执行手册，补上环境绑定的采样命令、停止条件和恢复验收。