如何理解MySQL中的意向锁（IS/IX）及其在表级锁中的作用？-mysql教程-PHP中文网

意向锁本身不阻塞操作，仅作表级快速冲突检测：is由select ... lock in share mode触发，ix由select ... for update、update、delete、insert自动触发；二者彼此兼容，但is阻塞write表锁、允许read表锁，ix则阻塞所有表锁。

如何理解mysql中的意向锁（is/ix）及其在表级锁中的作用？

意向锁本身不阻塞任何操作，但它是表级锁能否快速通过的关键开关——没它，加个 LOCK TABLES t WRITE 就得扫全表行锁；有它，一次查 data_locks 就能拒绝或放行。

IS 和 IX 锁到底由什么语句触发？

你写不出 LOCK TABLE t INTENTION SHARE 这种语法，因为 IS/IX 是 InnoDB 自动加的，只取决于你执行的语句类型：

SELECT ... LOCK IN SHARE MODE → 自动加 IS 锁（同时对命中行加 S 行锁）
SELECT ... FOR UPDATE、UPDATE、DELETE、INSERT → 自动加 IX 锁（即使 INSERT 没显式锁，也可能因唯一约束检查触发）
没走索引的 UPDATE 或 DELETE（如 WHERE non_indexed_col = 'x'）→ 仍加 IX，但会为每行加 X 行锁，效果接近“伪表锁”

为什么表锁要查意向锁，而不是直接扫行？

一张千万行的表，如果每次加 LOCK TABLES t WRITE 都得遍历所有行判断是否被 SELECT FOR UPDATE 锁住，光锁检测就可能卡几秒。意向锁就是这个瓶颈的解法：

IS 表示“我准备对某些行加 S 锁”，不锁数据，只打标记
IX 表示“我准备对某些行加 X 锁”，同样不锁数据，只打标记
其他事务申请表锁时，只看表上有没有 IS 或 IX：有，就说明底下可能有行锁冲突，立刻决策；没有，直接通过

IS/IX 与表锁的兼容性怎么判断？

别记整张矩阵表，核心就两条规则：

MySQL

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

下载

IS 允许 LOCK TABLES t READ（读锁），但拒绝 LOCK TABLES t WRITE（写锁）
IX 拒绝所有表锁：READ 和 WRITE 都会被阻塞
IS 和 IX 彼此兼容——多个事务可同时持有，这是高并发的基础

验证方式：执行 SELECT object_schema,object_name,lock_type,lock_mode FROM performance_schema.data_locks WHERE lock_type = 'TABLE' AND lock_mode LIKE '%INTENTION%';，能看到 IS 或 IX 记录。