你了解MySQL的加锁规则吗？

注：加锁规则指的是next-key lock，若是还不了解next-key lock，请阅读上一篇博客

加锁规则能够归纳为：两个原则、两个优化和一个bug:

原则1:加锁的基本单位是next-key lock，前开后闭

原则2:查找过程当中访问到的对象才会加锁

优化1:索引上的等值查询，给惟一索引加锁的时候，next-key lock退化成行锁

优化2:索引上的等值查询，向右遍历时且最后一个值不知足等值条件的时候，next-key lock退化为间隙锁

1个bug:惟一索引上的范围查询会访问到不知足条件的第一个值为止。

——丁奇

这里用丁奇老师总结的规则，分场景进行分析：

测试数据：

CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `c` (`c`)
) ENGINE=InnoDB;

insert into t values(0,0,0),(5,5,5),
(10,10,10),(15,15,15),(20,20,20),(25,25,25);

接下来来看几个案例：

案例一：等值查询间隙锁

 

1. 因为数据库中没有 id=7这条数据，id又为主键索引，因此根据原则1可得：next-key lock的加锁范围是(5,10]。
2. SessionB要往这个间隙中插入id=8的数据，会被锁住，而SessionA是一个等值查询（id=7），且SessionCid=10的查询不知足查询条件（7 != 10），根据优化2可得，此时next-key lock退化成间隙锁：(5,10)

所以，SessionB会被阻塞，SessionC不会被阻塞

案例二：非惟一索引等值锁

1. 根据原则1，加锁的单位是next-key lock，所以会(0,5]加上next-key lock
2. c是普通索引，因此找到c=5这一条数据后，并不会停下，而是继续向右遍历，直到c=10，根据原则2，访问到的都要进行加锁，因此要给(5,10]加上next-key lock
3. 因为优化2，等值判断，向右遍历，最后一个值不知足c=5这个等值条件，因此next-key lock退化成间隙锁(5,10)
4. 根据原则2，访问到的数据才会加锁，又由于SessionB这个查询使用了覆盖索引，只须要访问主键索引，而主键索引并无加锁，因此SessionB能够执行。（锁是加在索引上的）SessionC要插入的元素位于(5,10)这个间隙锁的范围内，因此会被阻塞。

案例三：主键索引范围锁

1. SessionA的语句执行时，因为id是主键索引，找到了第一行id=10的数据，因此此时的next-key lock应该为(5,10]，根据优化1，主键id的等值条件，退化成行锁。
2. 日后继续查找，到id=15这一行停下来，所以须要加next-key lock(10,15]
3. 因此此时这个next-key lock的范围就是[10,15]

案例四:非惟一索引范围锁

 

相似于案例3，惟一不一样的地方是，在第一次使用c=10定位记录的时候，索引c上加上了(5,10]的next-key lock，这个next-key lock不会退化，因此最终SessionA加的锁是，索引c上的(5,10]和(10,15]这两个next-key lock

案例五:惟一索引范围锁bug

正常来讲，惟一索引的next-key lock应该是(10,15]，可是因为bug1，扫描到15后，还会继续扫描第一个不符合条件的值，所以还会存在一个next-key lock范围是(15,20]，这应该算是一个bug，由于(10,15]的next-key lock已经能够保证不会有范围内的数据插入。

案例六:limit语句加锁：

这两条语句的执行结果是同样的， 可是加锁范围却不同。

c是普通索引，因此SessionA加的next-key lock的范围是(5,10]和(10,15)

可是因为这里的limit已经明确了数据量的限制，所以在遍历到(c=10,id=30)这一行数据的时候，知足条件的语句已经有2条了。因此next-key lock的范围就变成了从(c=5,id=5)到(c=10,id=30)

经过这个案例，咱们能够获得一个结论， 在删除数据的时候，尽可能指定limit，这样不只能够控制删除数据的条数，让操做更安全，也能够减小加锁的范围。

案例七：死锁

1. sessionA启动事务后，执行查询语句加lock in share mode，在索引C上加上了next-key lock(5,10]和间隙锁(10,15)
2. SessionB的更新语句也要在c上加next-key lock(5,10]进入等待。
3. SessionA要再插入 （8，8，8）这一行，被SessionB的间隙锁锁住，出现了死锁。InnoDB让SessionB回滚。

这里就有一个问题，SessionB的 next-key lock(5,10]不是没申请成功吗？为何还会阻塞SessionA？

其实SessionB的加next-key lock(5,10]是分红 两步操做的，首先加(5,10)的间隙锁，在加c=10的行锁，间隙锁不是排他锁，因此加锁成功。也就是说next-key lock是分为间隙锁和行锁两端来执行的。