MySQL InnoDB引擎支持多粒度锁定机制，既可以对行加锁，也可以对表加锁，意向锁就是为了实现多粒度锁之间的快速冲突判断而设计的锁类型，分为意向共享锁IS和意向排他锁IX两类。
意向锁的核心作用
如果没有意向锁，当一个事务想要对整张表加表级锁时，需要逐行检查表中是否有行级锁存在，这个过程的性能开销会随着表数据量增大而急剧上升。意向锁的作用就是在事务对行加锁之前，先对表级添加一个对应的意向锁标记，这样其他事务想要加表级锁时，只需要检查表的意向锁即可快速判断是否存在冲突，不需要逐行扫描。
简单来说，意向锁是表级锁，但是它的存在是为了协调行级锁和表级锁的关系，本身不会阻塞除全表扫描以外的普通读写操作。
意向锁的触发规则
意向锁不需要用户手动添加，是InnoDB引擎自动管理的，触发规则如下：
- 当事务需要对表中的某些行加共享锁S时，会先自动给表加意向共享锁IS
- 当事务需要对表中的某些行加排他锁X时，会先自动给表加意向排他锁IX
多粒度锁冲突矩阵
不同锁类型之间的兼容性可以通过下面的冲突矩阵判断，兼容表示可以同时存在，不兼容表示会产生阻塞：
| 锁类型 | IS | IX | S | X |
|---|---|---|---|---|
| IS | 兼容 | 兼容 | 兼容 | 不兼容 |
| IX | 兼容 | 兼容 | 不兼容 | 不兼容 |
| S | 兼容 | 不兼容 | 兼容 | 不兼容 |
| X | 不兼容 | 不兼容 | 不兼容 | 不兼容 |
从矩阵可以看出，意向锁之间是完全兼容的，意向锁和行级锁的兼容性取决于行级锁的类型，只有表级排他锁X会和所有意向锁冲突，表级共享锁S只会和IX锁冲突。
实际案例分析
下面通过两个事务的操作案例，分析意向锁的冲突场景，首先创建测试表并插入数据：
-- 创建测试表
CREATE TABLE test_lock (
id INT PRIMARY KEY,
name VARCHAR(20)
) ENGINE=InnoDB;
-- 插入测试数据
INSERT INTO test_lock VALUES (1, 'test1'), (2, 'test2');
案例1：IX锁和S锁的冲突
开启两个事务，按照以下顺序执行：
-- 事务1 START TRANSACTION; -- 对id=1的行加排他锁，会自动给表加IX锁 SELECT * FROM test_lock WHERE id=1 FOR UPDATE; -- 事务2 START TRANSACTION; -- 尝试给表加共享锁，需要检查表的IX锁，会产生阻塞 LOCK TABLES test_lock READ;
此时事务2会被阻塞，因为表的IX锁和要加的S锁不兼容，直到事务1提交释放IX锁，事务2才能获取到表级S锁。
案例2：IS锁和IX锁的兼容
-- 事务1 START TRANSACTION; -- 对id=1的行加共享锁，自动加IS锁 SELECT * FROM test_lock WHERE id=1 LOCK IN SHARE MODE; -- 事务2 START TRANSACTION; -- 对id=2的行加排他锁，自动加IX锁，和IS锁兼容，不会阻塞 SELECT * FROM test_lock WHERE id=2 FOR UPDATE;
这个场景中事务2可以正常执行，因为IS和IX锁是兼容的，不会互相阻塞。
如何查看意向锁信息
当遇到锁等待问题时，可以通过MySQL的information_schema库下的锁相关表查看意向锁信息：
-- 查看当前锁信息，包含意向锁 SELECT * FROM information_schema.INNODB_LOCKS; -- 查看锁等待信息 SELECT * FROM information_schema.INNODB_LOCK_WAITS;
在查询结果中，lock_type为TABLE的就是意向锁，lock_mode字段会显示IS或者IX，结合冲突矩阵就可以快速判断锁冲突的原因。
总结
意向锁是InnoDB多粒度锁机制的重要组成部分，IS和IX锁的存在大幅提升了表级锁和行级锁的冲突判断效率。分析多粒度锁冲突时，只需要对照冲突矩阵，先确定涉及的锁类型，再判断兼容性即可。日常开发中遇到锁相关问题时，优先查看当前的锁类型和等待关系，结合意向锁的触发规则就能快速定位问题根源。