mysql 间隙锁和临键锁原理

以下面的表为例子进行说明

间隙锁的产生来自于 InnboDB 引擎在可重复读的级别基础上执行当前读时出现的幻读问题。下面来分析一下幻读的例子， 假如没有间隙锁的话 ，那么会出现下面的现象：

如上表如示，是基于没有间隙锁的假设，sessionA 事务内执行两次相同的当前读返回的数据不一样，出现幻读的现象。因为(2,2,10)这条记录在原本的数据并不存在，行锁就锁不住，因此诞生间隙锁。

首先看看sessionA的执行计划，发现用到覆盖索引

场景 1：插入到索引 a 时，要插入是索引是(11,5)，属于(a=10,id=10)和(a=30,id=30)之间的锁范围，所以阻塞

场景 2、3、4 同理分析得出结论

本例子跟《查询条件走二级索引例子》区别在于 sessionA 是 select * ，因此需要回到主键索引查询所有字段，扫描了主键索引，所以也会在扫描到的索引进行加 next-key lock。该语句回表一次，扫描到是行是 id=10，所以加锁是(0,10],(10,20)，因此 sessionA 一共加了锁是索引 a 的(10,30)和主键索引的（0,20）。

对于实验数据中的age列，现有的数据为1，5，9，11，那么针对age列将会有1，5，9，11这4个锁，当筛选条件中的column被精准命中时，也就是说sql中写成where age = x时，这是被 *** 作的记录，将会被锁定。举个例子：

开启2个事物session1，session2

直接执行行3，箭头指向的位置一直在转圈，无法对age=5的记录加排它锁。

现有的数据为1，5，9，11，那么对于age列，将会有以下几个开区间

(-∞, 1), (1, 5), (5, 9), (9, 11), (11, +∞)。

直接执行行4，能看到一直在转圈。因为age >6 and age <8落在了（9， 11）这个开区间内，那么(9, 11)这个开区间内的与age列相关的dml语句都会被锁。这里演示的是insert，那么update的？没有update，因为既然有(9, 11)这个开区间，那么就说明(9, 11)的间隙里没有数据。

与间隙锁的区别：查询条件落只在间其中一个开区间内，将会进行锁定。临键锁则是，当查询条件跨越了超过一个开区间，比如：where age >6 and age <10，这个条件落在了(5, 9), (9, 11)这2个区间内，它让存在的记录锁里的age=9也被包含在了符合的条件里。这是就会有如下临键锁了

(-∞, 1], (1, 5], (5, 9], (9, 11], (11, +∞)，可以看到临键锁就是记录锁与间隙锁的并集，是一个左开右必的区间。这是，将会对被落到的区间内的符合条件的记录进行锁定，(5, 9], (9, 11]被锁定，也就是(5, 11]这个区间内的记录被锁定了。下面来 *** 作：