为什么MySQL 8.0删除了innodb_locks表_改用data_locks表查询锁-mysql教程-PHP中文网

mysql 8.0 直接移除了 information_schema.innodb_locks 表，因其仅显示有等待关系的锁、不区分锁粒度、权限要求过高且与 performance schema 架构割裂；改用 performance_schema.data_locks 表，具备始终可见、字段语义清晰、支持跨表关联和细粒度权限等优势。

为什么mysql 8.0删除了innodb_locks表_改用data_locks表查询锁

MySQL 8.0 直接移除了 INFORMATION_SCHEMA.INNODB_LOCKS 表，不是“弃用后推荐替代”，而是物理删除 —— 所有依赖它的脚本、监控或运维查询在升级到 8.0.3+ 后会直接报错 “Table doesn’t exist”。

为什么删掉 `INNODB_LOCKS`？它到底有什么问题

这个表本质是 InnoDB 内部锁结构的快照视图，但设计上存在几个硬伤：

只显示“有等待关系”的锁：如果一个事务持有一个 X 锁，但当前没别的事务在等它，INNODB_LOCKS 就不会返回这条记录 —— 导致你误判“没锁”，实际只是“没人卡住”
不区分锁粒度：行锁、间隙锁、临键锁、表锁全混在一个字段里，LOCK_MODE 值含义模糊（比如 INSERT_INTENTION 和 X,GAP 容易混淆）
权限模型不一致：查它需要全局 PROCESS 权限，而很多生产环境只给 DBA 或监控账号最小权限集，这成了安全瓶颈
和 Performance Schema 架构割裂：它属于旧式 Information Schema 插件体系，无法与 events_waits_current、线程栈等 P_S 表做关联分析

`data_locks` 表解决了哪些关键问题

performance_schema.data_locks 不是简单重命名，而是重构了锁信息的采集逻辑和语义表达：

始终可见：只要事务持有锁（哪怕完全没人等待），data_locks 就一定有对应行 —— 真实反映“当前谁拿了什么锁”
字段语义清晰：LOCK_TYPE 明确区分 TABLE / RECORD；LOCK_MODE 严格按标准命名（X,REC_NOT_GAP、S,GAP、INSERT_INTENTION）
支持跨表关联：通过 THREAD_ID 可直接连到 threads 表查 SQL、用户、客户端 IP；通过 ENGINE_TRANSACTION_ID 可连到 data_lock_waits 查阻塞链
权限更细粒度：只需对 performance_schema.data_locks 有 SELECT 权限，无需全局 PROCESS

升级后最常踩的坑：字段名和值变了，不能直接替换

很多团队把旧脚本里的 INNODB_LOCKS.LOCK_TRX_ID 直接改成 DATA_LOCKS.ENGINE_TRANSACTION_ID，结果查不到数据 —— 因为：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

INNODB_LOCKS.LOCK_TRX_ID 是十六进制字符串（如 123456789ABC），而 DATA_LOCKS.ENGINE_TRANSACTION_ID 是十进制 bigint
INNODB_LOCKS.LOCK_DATA 在主键锁时显示主键值，但在 DATA_LOCKS 中，即使走主键，也可能为 NULL（例如锁的是聚簇索引头页、或页面不在 buffer pool）
INNODB_LOCKS 的 LOCK_INDEX 字段在 DATA_LOCKS 中拆成了 INDEX_NAME + OBJECT_NAME，且 INDEX_NAME 为 PRIMARY 时不表示“主键索引”，而表示“聚簇索引”，这点容易误解
旧查询习惯用 LOCK_TRX_ID 关联 INNODB_TRX，现在得用 ENGINE_TRANSACTION_ID 关联 performance_schema.events_transactions_current（注意不是 INNODB_TRX！该表也已弱化）

一个能跑通的最小排查链路

想快速定位“谁在等谁”，别再拼 INNODB_LOCK_WAITS，用这套组合：

SELECT
  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  r.trx_query waiting_query,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread,
  b.trx_query blocking_query
FROM performance_schema.data_lock_waits w
JOIN information_schema.INNODB_TRX b ON b.trx_id = w.BLOCKING_ENGINE_TRANSACTION_ID
JOIN information_schema.INNODB_TRX r ON r.trx_id = w.REQUESTING_ENGINE_TRANSACTION_ID;

注意：data_lock_waits 是唯一保留“请求-阻塞”映射关系的表，但它依赖 INNODB_TRX 查 SQL —— 所以仍需保留对 INNODB_TRX 的访问（它没被删，只是功能收窄）。真正彻底脱离旧 I_S 的方案，得用 events_statements_current 关联线程 ID，但那要处理更复杂的事件生命周期。

真实线上锁问题往往卡在“锁住了但没等待”，这时候只查 data_lock_waits 是空的，必须先看 data_locks 找出活跃锁，再结合事务状态和 SQL 文本判断是否异常 —— 这个思维切换，比语法迁移更重要。