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 锁现在更容易成为瓶颈，且错误更隐蔽。
