MySQL的锁机制分为表级锁和行级锁两类，当同一个事务中同时存在表锁和行锁的操作时，数据库需要判断不同锁之间是否兼容，避免数据读写冲突。意向锁IS和IX是MySQL InnoDB引擎引入的表级锁，专门用来优化表锁和行锁的兼容性检查流程。
意向锁IS与IX的基本概念
意向锁分为两种类型，分别是意向共享锁（Intention Shared Lock，简称IS）和意向排他锁（Intention Exclusive Lock，简称IX），它们的核心作用是提前声明事务后续的行锁加锁意图。
- 意向共享锁IS：当事务想要给表中的某些行加共享锁（S锁）时，需要先获取该表的IS锁。比如执行
SELECT ... LOCK IN SHARE MODE语句时，事务会先对表加IS锁，再对符合条件的行加S锁。 - 意向排他锁IX：当事务想要给表中的某些行加排他锁（X锁）时，需要先获取该表的IX锁。比如执行
SELECT ... FOR UPDATE或者更新、删除操作时，事务会先对表加IX锁，再对符合条件的行加X锁。
需要注意的是，意向锁是表级锁，但是不会阻塞除全表扫描以外的任何请求，它的存在只是为了快速判断锁的兼容性。
锁的兼容性规则
MySQL的锁兼容性主要分为表级锁之间的兼容性，以及表级锁和行级锁之间的兼容性，意向锁的加入让这些判断更加高效。我们先看基础的锁类型兼容表：
| 锁类型 | IS锁 | IX锁 | S锁（表级） | X锁（表级） |
|---|---|---|---|---|
| IS锁 | 兼容 | 兼容 | 兼容 | 冲突 |
| IX锁 | 兼容 | 兼容 | 冲突 | 冲突 |
| S锁（表级） | 兼容 | 冲突 | 兼容 | 冲突 |
| X锁（表级） | 冲突 | 冲突 | 冲突 | 冲突 |
从表中可以看出，意向锁之间是完全兼容的，因为意向锁只是声明加锁意图，不会真正锁定行数据，所以多个事务可以同时持有同一个表的IS锁或者IX锁。而表级的S锁和X锁会和对应的意向锁产生冲突，这就是优化兼容性检查的核心逻辑。
意向锁如何提升兼容性检查效率
在没有意向锁的场景下，如果事务A已经对表中的某一行加了行级X锁，此时事务B想要对整张表加表级X锁，那么数据库需要逐行检查表中是否已经有行级锁存在，这个逐行扫描的过程在表数据量大的时候会非常耗时。
引入意向锁之后，这个检查流程就会变得非常简单：
- 事务A要对某行加X锁，会先获取表的IX锁，再对行加X锁。
- 事务B想要加表级X锁时，只需要检查表上是否已经存在和X锁冲突的锁，也就是IS锁、IX锁、S锁、X锁中的任意一种。
- 此时表上已经有事务A持有的IX锁，和事务B要加的表级X锁冲突，所以事务B会直接阻塞，不需要逐行扫描。
我们可以通过一个简单的示例来验证这个流程，首先创建测试表并插入数据：
-- 创建测试表
CREATE TABLE test_lock (
id INT PRIMARY KEY,
name VARCHAR(20)
) ENGINE=InnoDB;
-- 插入测试数据
INSERT INTO test_lock VALUES (1, 'test1'), (2, 'test2');
然后开启两个事务模拟加锁场景：
-- 事务A START TRANSACTION; -- 对id=1的行加排他锁，此时会先获取表的IX锁，再对行加X锁 SELECT * FROM test_lock WHERE id = 1 FOR UPDATE; -- 事务B（另一个连接执行） START TRANSACTION; -- 尝试对整张表加表级排他锁，此时会检查到表上有IX锁，直接冲突阻塞 LOCK TABLES test_lock WRITE;
在这个示例中，事务B不需要扫描全表就能快速判断出锁冲突，这就是意向锁带来的效率提升。
意向锁的使用注意事项
意向锁是InnoDB引擎自动管理的，开发者不需要手动去申请或者释放意向锁，只要执行行锁相关的操作，引擎会自动处理意向锁的获取和释放。
另外意向锁只会和表级锁产生冲突，不会和行级锁产生冲突，因为行级锁的兼容性检查是通过记录锁、间隙锁等机制单独处理的，意向锁只负责表级锁和行锁之间的快速兼容性判断，两者是配合工作的关系。
如果业务中经常出现表锁和行锁混合使用的场景，意向锁的存在会大幅降低锁检查的开销，避免全表扫描带来的性能问题。理解意向锁的工作机制，也有助于我们在遇到锁等待、死锁等问题时，更准确地分析问题的根源。