innodb_locks表在mysql 8.0.24+已被移除，应改用performance_schema.data_locks和data_lock_waits；意向锁阻塞实为mdl等待，需结合metadata_locks、data_locks及innodb_trx定位持有ix/is锁的长事务。
information_schema.innodb_locks 表在 MySQL 8.0.24+ 已被移除，直接查它会报错 Table 'information_schema.innodb_locks' doesn't exist。所以“通过 innodb_locks 表对比排查意向锁阻塞”这个思路本身已失效，不是操作不对，而是对象不存在了。
为什么查不到 innodb_locks？
MySQL 官方从 8.0.24 版本起彻底废弃了 innodb_locks 和 innodb_lock_waits 这两张表，改用 performance_schema.data_locks 和 performance_schema.data_lock_waits 替代。很多线上环境已升级到 8.0.25/26，但排查文档没同步更新，导致 DBA 或开发仍按老方式执行，卡在第一步就失败。
意向锁（IS/IX）本身不显式出现在旧表中——它只作为元信息存在于事务加锁过程中，innodb_locks 原本就不展示意向锁，只展示行锁/间隙锁等具体锁实例。所以即使能查，也看不到 IS/IX 的“阻塞行为”，只能靠间接推断。
真正能定位意向锁阻塞的替代方案
意向锁阻塞的本质是：一个事务持有表级意向锁（如 IX），另一个事务试图对该表加**冲突的表级锁**（如 LOCK TABLES ... WRITE 或 FLUSH TABLES WITH READ LOCK），或执行 DDL（如 ALTER TABLE）。此时阻塞不会体现为“行锁等待”，而表现为会话长期卡在 Waiting for table metadata lock 状态。
- 用
SHOW PROCESSLIST找出状态为Waiting for table metadata lock的线程，记下其ID - 查
performance_schema.metadata_locks，过滤该线程 ID，确认它在等哪张表、哪种锁类型（LOCK_TYPE = 'EXCLUSIVE'或'SHARED_WRITE'） - 再查
performance_schema.data_locks，找正在活跃事务（ENGINE_TRANSACTION_ID）持有的锁，重点看OBJECT_SCHEMA/OBJECT_NAME和LOCK_MODE中是否含IX或IS（LOCK_MODE字段值为IX或IS即表示意向锁） - 结合
information_schema.INNODB_TRX查对应事务的 SQL 和运行时间，判断是否长事务未提交，导致 IX 锁迟迟不释放
常见误判点：把 MDL 等待当成行锁等待
意向锁本身不阻塞其他 DML（UPDATE/INSERT/SELECT FOR UPDATE），它只和真正的表级锁（MDL）冲突。但很多人看到 Waiting for table metadata lock 就去翻 data_lock_waits，结果找不到等待链——因为这不是 InnoDB 层的锁等待，而是 Server 层的 MDL 等待。
关键区别：
-
data_lock_waits：只反映 InnoDB 存储引擎内部的行锁/间隙锁等待（比如两个事务争同一行 X 锁） -
metadata_locks+threads：反映 Server 层的表级元数据锁等待（比如 ALTER 正在等 SELECT FOR UPDATE 事务释放 IX 锁） - 意向锁（IX/IS）本身不直接“阻塞”，它只是让 Server 层拒绝授予冲突的 MDL —— 阻塞源头永远是那个持有 IX/IS 的活跃事务
真正难的不是查意向锁，而是区分清楚：当前卡住是 InnoDB 行锁层面的问题，还是 Server 层 MDL 层面的问题。一旦混淆，所有后续查询都跑偏方向。
