深入理解MySQL的间隙锁

因为行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的“间隙”。为了解决幻读问题，InnoDB 只好引入新的锁，也就是间隙锁 (Gap Lock)。

间隙锁，锁的就是两个值之间的空隙，不允许两个值之间再插一个值。

比如初始化插入了 6 个记录，这就产生了 7 个间隙。分别是 (-∞,0)、(0,5)、(5,10)、(10,15)、(15,20)、(20, 25)、(25, +supremum)，间隙锁都是开区间

和行锁不一样的是，跟间隙锁存在冲突关系的，是“往这个间隙中插入一个记录”这个 *** 作。间隙锁之间都不存在冲突关系。

缺点：可能会导致同样的语句锁住更大的范围，影响了并发度。

间隙锁和行锁合称 next-key lock，每个 next-key lock 是前开后闭区间。如果用 select * from t for update 要把整个表所有记录锁起来，就形成了 7 个 next-key lock，分别是 (-∞,0]、(0,5]、(5,10]、(10,15]、(15,20]、(20, 25]、(25, +supremum]。

和间隙锁的最大区别是，next-key lock 为前开后闭区间，这样所有的next-key lock就可以把所有记录锁起来。

加锁规则里面，包含了两个“原则”、两个“优化”和一个“bug”

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

间隙锁的产生来自于 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）。

---