意向锁（IS/IX）需通过performance_schema.data_locks查询，LOCK_TYPE=TABLE且LOCK_MODE=IS/IX即表示存在，不阻塞其他意向锁但会阻止X表锁。
怎么看事务持有哪些意向锁
意向锁（IS/IX）本身不直接显示在 SHOW ENGINE INNODB STATUS 的 LOCK WAIT 部分，它只出现在事务的 LOCKS 行中，且必须结合 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCKS（MySQL 5.7）或 performance_schema.data_locks（MySQL 8.0+）交叉查证。
MySQL 8.0 推荐用这个查询定位：
SELECT ENGINE_TRANSACTION_ID, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_DATA FROM performance_schema.data_locks WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table';
其中 LOCK_MODE 显示 IS 或 IX，LOCK_TYPE 是 RECORD 或 TABLE —— 意向锁永远是 TABLE 级别，但 LOCK_DATA 为空（区别于行锁）。
- 如果只看到
LOCK_TYPE = TABLE且LOCK_MODE是IS/IX，说明该事务没持任何行锁，只申请了意向锁（比如执行了SELECT ... LOCK IN SHARE MODE但没命中任何行） - 若同时存在
RECORD锁和TABLE级IX，说明事务正在修改数据，IX 是自动加上的，不能被绕过 - MySQL 5.7 中
INNODB_LOCKS已废弃且不准确，别依赖它判断意向锁是否存在
IS 和 IX 冲突的实际表现
意向锁存在的唯一意义就是提前宣告“我接下来要锁里面的东西”，所以它的冲突规则非常机械：IS 与 S/X 冲突，IX 与 X/S 冲突 —— 但只在表级互斥，不阻塞其他意向锁。
典型卡住场景：
- 事务 A 执行
SELECT * FROM t WHERE id = 100 LOCK IN SHARE MODE→ 加 IS + S 行锁 - 事务 B 同时执行
ALTER TABLE t ADD COLUMN c INT→ 需要X表锁 → 被 A 的 IS 阻塞（因为 IS 与 X 冲突） - 事务 C 执行
INSERT INTO t VALUES (200)→ 加 IX → 不被 A 阻塞（IX 与 IS 兼容）
注意：IX 和 IS 可以共存，但任意一个 IX 或 IS 都会阻止外部请求的 X 表锁（如 DDL、TRUNCATE），这是线上 DDL 卡住最常见的底层原因。
为什么 SELECT ... FOR UPDATE 会触发 IX 而不是 IS
意向锁类型取决于后续真实加的锁粒度。InnoDB 规则很直接：FOR UPDATE 或 UPDATE/DELETE 必然走 IX；LOCK IN SHARE MODE 或纯读事务中的 SELECT 加共享锁，走 IS。
- 哪怕你
SELECT * FROM t WHERE id = 1 FOR UPDATE只锁一行，InnoDB 仍先加 IX 表锁，再加 X 行锁 - 如果
WHERE条件无索引导致全表扫描，IX 会升级为实际的X表锁（此时已不是意向锁，是真锁） -
SELECT ... LOCK IN SHARE MODE在可重复读下可能触发间隙锁（GAP），但它仍只申请 IS，不会升级成 IX
验证方式：在另一个会话里执行 ALTER TABLE t ENGINE=INNODB，如果卡住，说明有未提交事务持 IX 或 IS；再用 data_locks 查具体是哪种。
排查锁冲突时最容易忽略的一点
意向锁本身不记录等待链，也不出现在 INNODB_STATUS 的 “TRANSACTIONS” section 的 lock wait 描述里。你看到“waiting for table metadata lock”或者“Waiting for table level lock”，大概率是意向锁在背后挡路，但错误信息完全不提 IS/IX。
这时候光看 SHOW PROCESSLIST 没用，必须立刻查 performance_schema.data_lock_waits（8.0）或临时启用 innodb_status_output_locks（5.7）。
更隐蔽的是：长事务即使只执行过一条 SELECT ... LOCK IN SHARE MODE，只要没提交，它的 IS 就一直挂着，足以让后续所有 DDL 僵住 —— 这类问题往往在业务低峰期改表时突然暴露，而源头事务可能几小时都没动静。
