MySQL 5.7与8.0 information_schema锁视图区别

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