mysql如何分析意向锁(IS/IX)_mysql多粒度锁冲突分析-mysql教程-PHP中文网

意向锁（is/ix）需通过performance_schema.data_locks查询，lock_type=table且lock_mode=is/ix即表示存在，不阻塞其他意向锁但会阻止x表锁。

mysql如何分析意向锁(is/ix)_mysql多粒度锁冲突分析

怎么看事务持有哪些意向锁

意向锁（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 卡住最常见的底层原因。

MySQL

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

下载

为什么 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 僵住 —— 这类问题往往在业务低峰期改表时突然暴露，而源头事务可能几小时都没动静。