MySQL中行锁的算法

行锁的3中算法

Record Lock:单个行记录上的锁

Gap Lock:间隙锁,锁定一个范围，但不包含记录本身

Next-key Lock:Gap Lock+Record Lock锁定一个范围，并且锁定记录本身

Record Lock总是会去锁住索引记录，如果InnoDB存储引擎表在建立的时候没有设置任何一个索引，那么这是会使用隐式的主键来进行锁定

Next-Key Lock是结合Gap Lock和Record Lockd 一种锁定算法，在Nex-Key Lock算法下，InnoDB对于行的查询都是采用这种锁定算法，例如一个索引有10 11 13 20这四个值，那么该索引可能被Next-Key Locking的区间为:

看一下执行表的SQL语句

表t共有1 2 5 三个值，在会话A中首先对a=5进行了X锁定。而由于a是主键且唯一，因此锁定的仅是5这个值，而不是(2,5)这个范围，这样在会话B中插入4不会阻塞，可以立即插入并返回，及锁定由Next-Key Lock算法降级为了Record Lock，从而提高应用的并发性

正如前面介绍，Next-Key Lock 降级为Record Lock仅在查询的列是唯一索引的情况下，如果是辅助索引，有不同

>create table z(a INT,b INT, PRIMARY KEY(a),KEY(b));

>INSERT INTO z SELECT 1,1;

>INSERT INTO z SELECT 3,1;

>INSERT INTO z SELECT 5,3;

>INSERT INTO z SELECT 7,6;

>INSERT INTO z SELECT 10,8;

表z的列b是辅助索引，若在会话A中执行下面的SQL语句

>SELECT  * FROM z WHERE b=3 FRO UPDATE;

很明显，这是SQL语句通过索引b进行查询，因此使用传统的Next-Key Locking技术加锁，并且由于有两个索引，其需要分别进行锁定，对于聚集索引，其仅对列a等于5的索引加Record Lock,而对于辅助索引，其加上了Next-Key Lock，锁定的范围是(1,3)特别需要注意的是，InnoDB存储引擎还会对辅助索引的下一个键值加上gap lock，即还有一个辅助索引范围为(3,6)的锁。因此在会话B中运行下面语句会被阻塞

>SELECT * FROM z WHERE a=5 LOCK IN SHARE MODE;

>INSERT INTO z SELECT 4,2;

>INSERT INTO z SELECT 6,5;

第一个SQL语句不能执行，因为在会话A中执行的SQL语句已经对聚集索引中的列a=5的值做了X锁，因此执行会阻塞，第二个SQL语句，主键插入4，没有问题，但是辅助索引2在锁定的范围(1,3)中，因此执行同样会被阻塞。第三个SQL语句，插入主键6没有被锁定，5也不再范围(1,3)之间，但是插入的值5在另一个锁定的范围(3,6)中，故同样需要等待。而下面的SQL语句，不会被阻塞。可以理解执行

>INSERT INTO z SELECT 8,6;

>INSERT INTO z SELECT 2,0;

>INSERT INTO z SELECT 6,7;

从上面的例子可以看到，Gap Lock的作用是为了阻止多个事务将记录插入到同一个范围内，而这会导致Phantom Problem问题的产生。例如上面例子中，会话A中用户已经锁定了b=3的记录，若此时没有Gap Lock锁定(3,6)那么用户可以插入索引b列为3的记录，这样会导致会话A中的用户再次执行同样查询时会返回不同的记录，即导致Phantom Problem问题的产生。

用户可以通过以下两种方式来显式的关闭Gap Lock:

将事务的隔离级别设成RC

将参数innodb_locks_unsafe_for_binlog 设置为1

在上述配置中，除了外键约束和唯一性约束检查依然需要Gap Lock，其余情况仅适用于Record Lock进行锁定，但需要牢记，上述设置破坏了事务的隔离性，并且对于replication，可能会导致主从不一致。此外，从性能上看，RC也不会优于默认的事务隔离级别RR

在InnoDB存储引擎中，对于INSERT操作，其会检查插入记录的下一条记录是否被锁定，若已经被锁定，则不允许查询，对于上面例子，会话A已经锁定了表z中b=3的记录，即已经锁定(1,3)范围，这是若在其他会话插入同样的会导致阻塞

>INSERT INTO t SELECT 2,2;

因为在辅助索引b上插入值为2的记录时，会检测到下一个记录3已经被索引，而将插入的值修改为如下的值，则可以立即执行

>INSERT INTO t SELECT 2,0;

需要再次提醒，对于唯一键值的锁定，Next-Key Lock降级为Record Lock进存在于查询所有的唯一索引列。若唯一索引由多个列组成，而查询仅是查找多个唯一索引列中的其中一个，那么查询其实是range类型查询，而不是point类型查询，故InnoDB存储引擎依然使用Next-Key Lock进行锁定