mysql间隙锁怎么加 mysql加锁过程详解

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

mysql要加上nextkey锁，语句该怎么写

如果在transaction1(Tr1)进行一个

select * from table1 where id 4 lock in share mode.

这里会在table1上加一个next_key lock(间隙锁)，基本原理是什么呢？大致是这样的，内存中有一个lock hash。是一个key（类似于tableid+pageid+offset）到value（所加的锁）--- 这就是行锁的原理。所以 id4的话，会给0 1 2 4(假设当前数据库没有3)加上行锁，这样就保证了不会出现插入id=3.5这种事情的发生。

深入理解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”

mysql 的锁以及间隙锁

mysql 为并发事务同时对一条记录进行读写时，提出了两种解决方案：

1）使用 mvcc 的方法，实现多事务的并发读写，但是这种读只是“快照读”，一般读的是历史版本数据，还有一种是“当前读”，一般加锁实现“当前读”，或者 insert、update、delete 也是当前读。

2）使用加锁的方法，锁分为共享锁（读锁），排他锁（写锁）

快照读：就是select

当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。

mysql 在 RR 级别怎么处理幻读的呢？一般来说，RR 级别通过 mvcc 机制，保证读到低于后面事务的数据。但是 select for update 不会触发 mvcc，它是当前读。如果后面事务插入数据并提交，那么在 RR 级别就会读到插入的数据。所以，mysql 使用行锁 + gap 锁（简称 next-key 锁）来防止当前读的时候插入。

Gap Lock在InnoDB的唯一作用就是防止其他事务的插入操作，以此防止幻读的发生。

Innodb自动使用间隙锁的条件：

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）。

MySQL白菜教程（Level 10 - 意向锁&记录锁&间隙锁）

意向锁（Intention Locks; table-level lock）

意向锁是一种特殊的表级锁，意向锁是为了让 InnoDB 多粒度的锁能共存而设计的。取得行的共享锁和排他锁之前需要先取得表的意向共享锁（IS）和意向排他锁（IX），意向共享锁和意向排他锁都是系统自动添加和自动释放的，整个过程无需人工干预

意向锁就是指未来的某一个时刻事务可能要加共享锁或者排它锁，提前声明一个意向，分为两种：

意向共享锁（Intention Shared Lock） IS

事务有意向对表中的某些行加共享锁（S锁）

意向排它锁（Intention Exclusive Lock）IX

事务有意向对表中的某些行加排他锁（X锁）

记录锁（Record Locks）

官方原文

SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; 这一行则是使用了记录锁，不允许其他事务进行增，删，改

但是 SELECT c1 FROM t WHERE c1 = 10; 是没有锁的，走的是快照读，上文已经阐明过了

记录锁本身不是锁定记录数据本身而是锁定索引记录，如果要锁的列没有索引，则会进行全表记录加锁

间隙锁（Gap Locks）

官方原文

比如 SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE ;

插入 c1 为 15 的记录会被锁定不可执行

这种默认存在于可重复读的事务隔离级别中的锁，锁定被圈定的范围不允许 insert，防止不可重复读，上文说了我们的事务隔离级别都是读已提交，默认会产生不可重复读的问题

间隙锁和行锁加锁规则

表和数据

规则总结（这个规则只限于截止到现在的最新版本，即 5.x 系列 =5.7.24，8.0 系列 =8.0.13。）：

原则 1：加锁的基本单位是 next-key lock。希望你还记得，next-key lock 是前开后闭区间。

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

优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。

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

一个 bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止。

案例一：等值查询间隙锁

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

根据原则1，优化2，锁的范围是(0,5],(5,10)，但是根据原则2，只有访问到的对象才加锁，这个查询使用了覆盖索引，并不访问主键索引，所以主键上没加锁。

需要注意，在这个例子中，lock in share mode 只锁覆盖索引，但是如果是 for update 就不一样了。执行 for update 时，系统会认为你接下来要更新数据，因此会顺便给主键索引上满足条件的行加上行锁。

案例三：主键索引范围锁

案例四：非唯一索引范围锁

这次 session A 用字段 c 来判断，加锁规则跟案例三唯一的不同是：在第一次用 c=10 定位记录的时候，索引 c 上加了 (5,10] 这个 next-key lock 后，由于索引 c 是非唯一索引，没有优化规则，也就是说不会蜕变为行锁，因此最终 sesion A 加的锁是，索引 c 上的 (5,10] 和 (10,15] 这两个 next-key lock。

案例五：唯一索引范围锁 bug

案例六：非唯一索引上存在"等值"的例子

表中插入一条mysql insert into t values(30,10,30);

这时，session A 在遍历的时候，先访问第一个 c=10 的记录。同样地，根据原则 1，这里加的是 (c=5,id=5) 到 (c=10,id=10) 这个 next-key lock。

然后，session A 向右查找，直到碰到 (c=15,id=15) 这一行，循环才结束。根据优化 2，这是一个等值查询，向右查找到了不满足条件的行，所以会退化成 (c=10,id=10) 到 (c=15,id=15) 的间隙锁。

案例七：limit 语句加锁

索引 c 上的加锁范围变成了从（c=5,id=5) 到（c=10,id=30) 这个前开后闭区间，如下图所示：

案例八：一个死锁的例子

在读提交情况下，语句执行过程中加上的行锁，在语句执行完成后，就要把“不满足条件的行”上的行锁直接释放了，不需要等到事务提交。

费解的问题

1.由于是 order by c desc，第一个要定位的是索引 c 上“最右边的”c=20 的行，所以会加上间隙锁 (20,25) 和 next-key lock (15,20]。

2.在索引 c 上向左遍历，要扫描到 c=10 才停下来，所以 next-key lock 会加到 (5,10]，这正是阻塞 session B 的 insert 语句的原因。