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