普通查询不申请锁，故不受意向锁影响；其通过MVCC实现快照读，不加行锁或表锁，而意向锁仅在事务申请行锁前自动设置，用于表级锁兼容性检查，本身不阻塞任何操作。

SELECT 这类普通查询根本不会申请任何锁，自然不受意向锁影响——意向锁本身也不拦它。

普通查询不申请锁，意向锁无从作用

MySQL 的 SELECT（无 FOR UPDATE 或 LOCK IN SHARE MODE）在默认隔离级别（REPEATABLE READ 或 READ COMMITTED）下走的是快照读（MVCC），不加任何行锁或表锁。意向锁只在事务真正要加行级 S/X 锁前由 InnoDB 自动前置申请，而普通查询连这一步都不触发，所以整个过程跟 IS、IX 完全无关。

意向锁只参与表锁兼容性检查

它存在的唯一作用，是让后续申请 LOCK TABLES ... WRITE 或 ALTER TABLE 这类表级排他操作时，能快速判断“底下有没有人正在动数据”。只要你不碰这些表锁，IS 和 IX 就像不存在一样——既不阻塞 SELECT，也不阻塞其他事务的 INSERT、UPDATE（只要它们操作的行不冲突）。

MySQL

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

下载

容易误判的典型场景

你以为 SELECT 被卡住了？大概率不是意向锁的问题：

• 实际是被别的事务的 SELECT FOR UPDATE 或 UPDATE 持有行锁，而你的查询恰好要读那几行（且隔离级别导致需要等锁释放）
• 执行了没走索引的 UPDATE，导致全表加 X 行锁 + IX，后续所有 DML 都排队，但普通 SELECT 仍不受影响
• 误把 SHOW ENGINE INNODB STATUS 里看到的 IX 当成阻塞源——它只是个标记，等待链里根本不会出现它

真正复杂的地方在于：意向锁看不见、摸不着，却决定着表锁能不能秒级获取；你查到它长期存在，说明背后事务没提交、SQL 慢、或者锁范围过大——得顺着 INFORMATION_SCHEMA.INNODB_TRX 往下挖，而不是盯着 IX 本身。