MySQL高级锁之意向锁

2.1 意向锁

2.1.1 意向锁的概念

意向锁的存在是为了协调行锁和表锁的关系，用于优化InnoDB加锁的策略。意向锁的主要功能就是：避免为了判断表是否存在行锁而去全表扫描。 意向锁是由InnoDB在操作数据之前自动加的，不需要用户干预；

• 意向共享锁（IS锁）：事务在请求S锁前，要先获得IS锁
• 意向排他锁（IX锁）：事务在请求X锁前，要先获得IX锁

场景举例（假设此时没有意向锁）：假设事务A锁住了表中的一行记录，之后，事务B申请整个表的写锁。数据库需要避免这种冲突，需要让B的申请被阻塞，直到A释放了行锁。数据库要怎么判断这个冲突呢？

• 方式1）：判断表中的每一行是否已被行锁锁住（效率非常低）
• 方式2）：直接判断整表是否已被其他事务用表锁锁表

意向锁就是在这个时候发挥作用的，有了意向锁。在意向锁存在的情况下，事务A必须先申请表的意向共享锁（表级锁），成功后再申请一行的行锁。下次事务B去申请表的排它锁时，发现有意向共享锁，说明表中肯定有某些行被锁住了，事务B将会阻塞； 当我们需要加一个排他锁时，需要根据意向锁去判断表中有没有数据行被锁定； （1）如果意向锁是行锁，则需要遍历每一行数据去确认； （2）如果意向锁是表锁，则只需要判断一次即可知道有没数据行被锁定，提升性能。 因此，意向锁是表级别的；

2.1.2 意向锁的应用

测试IS和IX之间是共享的，意向锁（共享和排他）和表级别的X锁是冲突的；

• 测试数据：

drop table if exists test4;

CREATE TABLE `test4`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) ,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = innodb ;

INSERT INTO test4 VALUES(1,'aa');
INSERT INTO test4 VALUES(2,'bb');

• 案例：

session-01	session-02
begin;
	begin;
select * from test4 where id=1 lock in share mode; -- 申请这行的共享锁
	select * from test4 for update; -- 申请整表的排它锁（阻塞）

示意图：

Tips：有了意向锁，在事务B申请表的排它锁时，MySQL就可以很轻松判断这个表中是否记录被锁住了；

2.1.3 意向锁与X/S锁之间的关系

我们之前说过，事务A在锁定一行记录时，会先加上意向锁（表级别），之后事务B申请整个表的排它锁时，先加上意向排它锁，发现该表已经被加上意向锁了，但是意向锁之间是兼容的，可以申请成功，之后事务B尝试申请表级别排它锁，申请锁失败，被阻塞；因为表级别的排它锁和意向锁是冲突的； 按照这个逻辑来说，如果此时事务B申请的是行锁呢（而且并不是事务A锁定的那一条记录）？根据意向锁是表锁的原则，那么此时事务B也会申请意向排它锁（表级别），这样下来不是会造成事务B阻塞吗？但事实并不是这样；因为所有的意向锁之间都是兼容的！ 测试意向锁和行级S/X锁是兼容的，并且所有的意向锁直接都是兼容的

• 测试案例：

session-01	session-02
begin;
	begin;
select * from test3 where id=1 lock in share mode; -- 申请这行的共享锁
	select * from test3 where id=2 for update; -- 申请这行的排它锁

示意图：

Tips：意向锁与行级的S/X锁之间的兼容的 关系如下：

	X	IX	S	IS
X（表级）	Conflict	Conflict	Conflict	Conflict
S（表级）	Conflict	Conflict	Compatible	Compatible
X（行级）	Conflict/Compatible	Compatible	Conflict/Compatible	Compatible
S（行级）	Conflict/Compatible	Compatible	Compatible	Compatible

注意：这里的排他 / 共享锁指的都是表锁！意向锁不会与行级的共享 / 排他锁互斥上了行级X锁后，行级X锁不会因为有别的事务上了IX而堵塞，一个mysql是允许多个行级X锁同时存在的，只要他们不是针对相同的数据行。