MySQL 8.0 已废弃 INFORMATION_SCHEMA.INNODB_LOCKS 和 INNODB_LOCK_WAITS，锁信息统一迁移至 performance_schema.data_locks 和 data_lock_waits，需启用 performance_schema 及相关 consumer 才能查到实时锁与锁等待。
MySQL 8.0 已彻底废弃 INFORMATION_SCHEMA.INNODB_LOCKS 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS，它们在 8.0 中始终返回空结果——不是没锁，而是视图本身已失效。
为什么查不到锁等待？因为视图被删了
5.7 时代，大家习惯靠 INFORMATION_SCHEMA.INNODB_LOCKS 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 来排查锁冲突。但这两个表有个天然缺陷：它们只在真实发生锁等待时才非空，而且只反映“正在等待”的那一瞬快照。到了 8.0，官方直接废弃了它们，你再执行 SHOW CREATE TABLE INFORMATION_SCHEMA.INNODB_LOCKS 会直接报错 Table 'INFORMATION_SCHEMA.INNODB_LOCKS' doesn't exist。
实际操作中，常见的坑有两个：
- 沿用 5.7 的老脚本跑
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS，返回空就以为“无锁等待”，实际上阻塞可能已经发生，只是视图不更新。 - 没打开
performance_schema或者没启用对应的 consumer，导致新视图也是空的，误判没锁。
8.0 必须用 performance_schema.data_locks 和 data_lock_waits
8.0 把所有锁信息统一搬到了 performance_schema 里，核心是两个表：
performance_schema.data_locks：展示当前每个事务持有的所有锁（包括那些还没冲突的锁），字段包括THREAD_ID、LOCK_MODE（比如X,REC_NOT_GAP）、LOCK_DATA。performance_schema.data_lock_waits：现在唯一靠谱的实时锁等待关系视图，字段有BLOCKING_ENGINE、BLOCKING_TRX_ID、BLOCKED_TRX_ID。
使用前必须确认三点：
performance_schema已启用（SELECT @@performance_schema返回ON）。- 相关 consumer 已开启：执行
SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'transactions%'，确保ENABLED = 'YES'。 - 如果仍为空，再去检查
performance_schema.setup_instruments中wait/lock/%是否启用。
5.7 和 8.0 锁视图行为差异直接影响排查逻辑
5.7 的 INNODB_LOCK_WAITS 是“被动触发式”：只有事务卡在 innodb_lock_wait_timeout 内拿不到锁，才会写入该表。而 8.0 的 data_lock_waits 是持续维护的等待图，只要阻塞存在就实时可见。
这意味着：
- 5.7 中，短于超时时间的锁等待可能根本不会出现在视图里。
- 8.0 中，即使等待刚发生 10ms，也能立刻查到
data_lock_waits记录。 - 8.0 支持单事务持锁查询（
data_locks），不需要构造冲突就能看到锁范围；5.7 必须让两个事务真正“撞上”才能看到锁信息。
别漏掉 MDL 锁和临时表参与锁管理
8.0 中，元数据锁（MDL）和临时表都被纳入了统一锁体系：
performance_schema.metadata_locks可以查 DDL 阻塞，重点关注LOCK_STATUS = 'PENDING'的记录。CREATE TEMPORARY TABLE也会申请 MDL 锁，高频创建/删除临时表的应用需要监控metadata_locks_cache_size。FLUSH TABLES WITH READ LOCK在 8.0 下会被 MDL 机制拒绝，旧备份脚本里如果还有这个命令，会直接失败。
这些变化让锁排查变得更全面，但也意味着你不能再只盯着 InnoDB 行锁了——MDL 锁现在更容易成为瓶颈，而且错误更隐蔽。
