MySQL的锁机制

MySQL的锁机制

 

咱们最简单的例子提及。常常有朋友发给我一个SQL，而后问我，这个SQL加什么锁？就如同下面两条简单的SQL，他们加什么锁？

• SQL1：select * from t1 where id = 10;
• SQL2：delete from t1 where id = 10;

针对这个问题？我能想象到的一个结论是：

• SQL1：不加锁。由于MySQL是使用多版本并发控制的，读不加锁。
• SQL2：对id = 10的记录加写锁 (走主键索引)。

这个对吗？说不上来。便可能是正确的，也有多是错误的，已知条件不足。若是让我来回复这个问题，我必须还要知道如下的一些前提，前提不一样，结论也就不一样。这个问题，还缺乏哪些前提条件？

前提一：id列是否是主键？

前提二：当前系统的隔离级别是什么？

前提三：id列若是不是主键，那么id列上有索引吗？

前提四：id列上若是有二级索引，那么这个索引是惟一索引吗？

前提五：两个SQL的执行计划是什么？索引扫描？全表扫描？

没有这些前提，直接就给定一条SQL，而后问这个SQL会加什么锁，都是很业余的表现。而当这些问题有了明确的以后，给定的SQL会加什么锁，也就一目了然。下面，我将这些问题进行组合，而后按照从易到难的顺序，逐个分析每种组合下，对应的SQL会加哪些锁？

先来温习下事物的隔离级别和锁的知识:

 

共享锁【S锁】

又称读锁，若事务T对数据对象A加上S锁，则事务T能够读A但不能修改A，其余事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其余事务能够读A，但在T释放A上的S锁以前不能对A作任何修改。

排他锁【X锁】

又称写锁。若事务T对数据对象A加上X锁，事务T能够读A也能够修改A，其余事务不能再对A加任何锁，直到T释放A上的锁。这保证了其余事务在T释放A上的锁以前不能再读取和修改A。

下面的这些组合，我作了一个前提假设，也就是有索引时，执行计划必定会选择使用索引进行过滤 (索引扫描)。但实际状况会复杂不少，真正的执行计划，仍是须要根据MySQL输出的为准。

• 组合一：id列是主键，RC隔离级别
• 组合二：id列是二级惟一索引，RC隔离级别
• 组合三：id列是二级非惟一索引，RC隔离级别
• 组合四：id列上没有索引，RC隔离级别
• 组合五：id列是主键，RR隔离级别
• 组合六：id列是二级惟一索引，RR隔离级别
• 组合七：id列是二级非惟一索引，RR隔离级别
• 组合八：id列上没有索引，RR隔离级别
• 组合九：Serializable隔离级别

排列组合尚未列举彻底，可是看起来，已经不少了。真的有必要这么复杂吗？事实上，要分析加锁，就是须要这么复杂。可是从另外一个角度来讲，只要你选定了一种组合，SQL须要加哪些锁，其实也就肯定了。接下来，就让咱们来逐个分析这9种组合下的SQL加锁策略。

注：在前面八种组合下，也就是RC，RR隔离级别下，SQL1：select操做均不加锁，采用的是快照读，所以在下面的讨论中就忽略了，主要讨论SQL2：delete操做的加锁。

组合一：id主键+RC(Read-Committed级别)

• 结论：id是主键时，此SQL只须要在id=10这条记录上加X锁便可。

组合二：id惟一索引+RC

• 这个组合，id不是主键，而是一个Unique的二级索引键值。那么在RC隔离级别下，delete from t1 where id = 10; 须要加什么锁呢？见下图：

 

此组合中，id是unique索引，而主键是name列。此时，加锁的状况因为组合一有所不一样。因为id是unique索引，所以delete语句会选择走id列的索引进行where条件的过滤，在找到id=10的记录后，首先会将unique索引上的id=10索引记录加上X锁。

同时，会根据读取到的name列，回主键索引(聚簇索引)，而后将聚簇索引上的name = ‘d’ 对应的主键索引项加X锁。为何聚簇索引上的记录也要加锁？试想一下，若是并发的一个SQL，是经过主键索引来更新：update t1 set id = 100 where name = ‘d';

此时，若是delete语句没有将主键索引上的记录加锁，那么并发的update就会感知不到delete语句的存在，违背了同一记录上的更新/删除须要串行执行的约束。

结论：若id列是unique列，其上有unique索引。那么SQL须要加两个X锁，一个对应于id unique索引上的id = 10的记录，另外一把锁对应于聚簇索引上的[name=’d’,id=10]的记录。

这个组合，是最简单，最容易分析的组合。id是主键，Read Committed隔离级别，给定SQL：delete from t1 where id = 10; 只须要将主键上，id = 10的记录加上X锁便可。以下图所示：

 

组合三：id非惟一索引+RC

相对于组合1、二，组合三又发生了变化，隔离级别仍旧是RC不变，可是id列上的约束又下降了，id列再也不惟一，只有一个普通的索引。假设delete from t1 where id = 10; 语句，仍旧选择id列上的索引进行过滤where条件，那么此时会持有哪些锁？一样见下图：

 

根据此图，能够看到，首先，id列索引上，知足id = 10查询条件的记录，均已加锁。同时，这些记录对应的主键索引上的记录也都加上了锁。与组合二惟一的区别在于，组合二最多只有一个知足等值查询的记录，而组合三会将全部知足查询条件的记录都加锁。

结论：若id列上有非惟一索引，那么对应的全部知足SQL查询条件的记录，都会被加锁。同时，这些记录在主键索引上的记录，也会被加锁。

组合四：id无索引+RC

相对于前面三个组合，这是一个比较特殊的状况。id列上没有索引，where id = 10;这个过滤条件，无法经过索引进行过滤，那么只能走全表扫描作过滤。对应于这个组合，SQL会加什么锁？或者是换句话说，全表扫描时，会加什么锁？这个也有不少：有人说会在表上加X锁；有人说会将聚簇索引上，选择出来的id = 10;的记录加上X锁。那么实际状况呢？请看下图：

 

因为id列上没有索引，所以只能走聚簇索引，进行所有扫描。从图中能够看到，知足删除条件的记录有两条，可是，聚簇索引上全部的记录，都被加上了X锁。不管记录是否知足条件，所有被加上X锁。既不是加表锁，也不是在知足条件的记录上加行锁。

有人可能会问？为何不是只在知足条件的记录上加锁呢？这是因为MySQL的实现决定的。若是一个条件没法经过索引快速过滤，那么存储引擎层面就会将全部记录加锁后返回，而后由MySQL Server层进行过滤。所以也就把全部的记录，都锁上了。

注：在实际的实现中，MySQL有一些改进，在MySQL Server过滤条件，发现不知足后，会调用unlock_row方法，把不知足条件的记录放锁 (违背了2PL的约束)。这样作，保证了最后只会持有知足条件记录上的锁，可是每条记录的加锁操做仍是不能省略的。

结论：若id列上没有索引，SQL会走聚簇索引的全扫描进行过滤，因为过滤是由MySQL Server层面进行的。所以每条记录，不管是否知足条件，都会被加上X锁。可是，为了效率考量，MySQL作了优化，对于不知足条件的记录，会在判断后放锁，最终持有的，是知足条件的记录上的锁，可是不知足条件的记录上的加锁/放锁动做不会省略。同时，优化也违背了2PL的约束。

组合五：id主键+RR

上面的四个组合，都是在Read Committed隔离级别下的加锁行为，接下来的四个组合，是在Repeatable Read隔离级别下的加锁行为。

组合五，id列是主键列，Repeatable Read隔离级别，针对delete from t1 where id = 10; 这条SQL，加锁与组合一：[id主键，Read Committed]一致。

组合六：id惟一索引+RR

与组合五相似，组合六的加锁，与组合二：[id惟一索引，Read Committed]一致。两个X锁，id惟一索引知足条件的记录上一个，对应的聚簇索引上的记录一个。

组合七：id非惟一索引+RR

RC隔离级别容许幻读，而RR隔离级别，不容许存在幻读。可是在组合5、组合六中，加锁行为又是与RC下的加锁行为彻底一致。那么RR隔离级别下，如何防止幻读呢？就在组合七中揭晓。

组合七，Repeatable Read隔离级别，id上有一个非惟一索引，执行delete from t1 where id = 10; 假设选择id列上的索引进行条件过滤，最后的加锁行为，是怎么样的呢？一样看下面这幅图：

 

此图，相对于组合三：[id列上非惟一锁，Read Committed]看似相同，其实却有很大的区别。最大的区别在于，这幅图中多了一个GAP锁，并且GAP锁看起来也不是加在记录上的，倒像是加载两条记录之间的位置，GAP锁有何用？

其实这个多出来的GAP锁，就是RR隔离级别，相对于RC隔离级别，不会出现幻读的关键。确实，GAP锁锁住的位置，也不是记录自己，而是两条记录之间的GAP。所谓幻读，就是同一个事务，连续作两次当前读 (例如：select * from t1 where id = 10 for update;)，那么这两次当前读返回的是彻底相同的记录 (记录数量一致，记录自己也一致)，第二次的当前读，不会比第一次返回更多的记录 (幻象)。

如何保证两次当前读返回一致的记录，那就须要在第一次当前读与第二次当前读之间，其余的事务不会插入新的知足条件的记录并提交。为了实现这个功能，GAP锁应运而生。

如图中所示，有哪些位置能够插入新的知足条件的项 (id = 10)，考虑到B+树索引的有序性，知足条件的项必定是连续存放的。记录[6,c]以前，不会插入id=10的记录；[6,c]与[10,b]间能够插入[10, aa]；[10,b]与[10,d]间，能够插入新的[10,bb],[10,c]等；[10,d]与[11,f]间能够插入知足条件的[10,e],[10,z]等；而[11,f]以后也不会插入知足条件的记录。所以，为了保证[6,c]与[10,b]间，[10,b]与[10,d]间，[10,d]与[11,f]不会插入新的知足条件的记录，MySQL选择了用GAP锁，将这三个GAP给锁起来。

Insert操做，如insert [10,aa]，首先会定位到[6,c]与[10,b]间，而后在插入前，会检查这个GAP是否已经被锁上，若是被锁上，则Insert不能插入记录。所以，经过第一遍的当前读，不只将知足条件的记录锁上 (X锁)，与组合三相似。同时仍是增长3把GAP锁，将可能插入知足条件记录的3个GAP给锁上，保证后续的Insert不能插入新的id=10的记录，也就杜绝了同一事务的第二次当前读，出现幻象的状况。

有心的朋友看到这儿，能够会问：既然防止幻读，须要靠GAP锁的保护，为何组合5、组合六，也是RR隔离级别，却不须要加GAP锁呢？

首先，这是一个好问题。其次，这个问题，也很简单。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的状况。而组合五，id是主键；组合六，id是unique键，都可以保证惟一性。一个等值查询，最多只能返回一条记录，并且新的相同取值的记录，必定不会在新插入进来，所以也就避免了GAP锁的使用。其实，针对此问题，还有一个更深刻的问题：若是组合5、组合六下，针对SQL：select * from t1 where id = 10 for update; 第一次查询，没有找到知足查询条件的记录，那么GAP锁是否还可以省略？此问题留给你们思考。

结论：Repeatable Read隔离级别下，id列上有一个非惟一索引，对应SQL：delete from t1 where id = 10; 首先，经过id索引定位到第一条知足查询条件的记录，加记录上的X锁，加GAP上的GAP锁，而后加主键聚簇索引上的记录X锁，而后返回；而后读取下一条，重复进行。直至进行到第一条不知足条件的记录[11,f]，此时，不须要加记录X锁，可是仍旧须要加GAP锁，最后返回结束。

组合八：id无索引+RR

组合八，Repeatable Read隔离级别下的最后一种状况，id列上没有索引。此时SQL：delete from t1 where id = 10; 没有其余的路径能够选择，只能进行全表扫描。最终的加锁状况，以下图所示：

 

如图，这是一个很恐怖的现象。首先，聚簇索引上的全部记录，都被加上了X锁。其次，聚簇索引每条记录间的间隙(GAP)，也同时被加上了GAP锁。这个示例表，只有6条记录，一共须要6个记录锁，7个GAP锁。试想，若是表上有1000万条记录呢？

在这种状况下，这个表上，除了不加锁的快照度，其余任何加锁的并发SQL，均不能执行，不能更新，不能删除，不能插入，全表被锁死。

固然，跟组合四：[id无索引, Read Committed]相似，这个状况下，MySQL也作了一些优化，就是所谓的semi-consistent read。semi-consistent read开启的状况下，对于不知足查询条件的记录，MySQL会提早放锁。针对上面的这个用例，就是除了记录[d,10]，[g,10]以外，全部的记录锁都会被释放，同时不加GAP锁。semi-consistent read如何触发：要么是read committed隔离级别；要么是Repeatable Read隔离级别，同时设置了innodb_locks_unsafe_for_binlog 参数。

结论：在Repeatable Read隔离级别下，若是进行全表扫描的当前读，那么会锁上表中的全部记录，同时会锁上聚簇索引内的全部GAP，杜绝全部的并发 更新/删除/插入 操做。固然，也能够经过触发semi-consistent read，来缓解加锁开销与并发影响，可是semi-consistent read自己也会带来其余问题，不建议使用。

组合九：Serializable

针对前面提到的简单的SQL，最后一个状况：Serializable隔离级别。对于SQL2：delete from t1 where id = 10; 来讲，Serializable隔离级别与Repeatable Read隔离级别彻底一致，所以不作介绍。

Serializable隔离级别，影响的是SQL1：select * from t1 where id = 10; 这条SQL，在RC，RR隔离级别下，都是快照读，不加锁。可是在Serializable隔离级别，SQL1会加读锁，也就是说快照读不复存在，MVCC并发控制降级为Lock-Based CC。

结论：在MySQL/InnoDB中，所谓的读不加锁，并不适用于全部的状况，而是隔离级别相关的。Serializable隔离级别，读不加锁就再也不成立，全部的读操做，都是当前读。

一条复杂的SQL

写到这里，其实MySQL的加锁实现也已经介绍的八八九九。只要将本文上面的分析思路，大部分的SQL，都能分析出其会加哪些锁。而这里，再来看一个稍微复杂点的SQL，用于说明MySQL加锁的另一个逻辑。SQL用例以下：

 

如图中的SQL，会加什么锁？假定在Repeatable Read隔离级别下 (Read Committed隔离级别下的加锁状况，留给读者分析。)，同时，假设SQL走的是idx_t1_pu索引。

在详细分析这条SQL的加锁状况前，还须要有一个知识储备，那就是一个SQL中的where条件如何拆分？具体的介绍，建议阅读我以前的一篇文章：SQL中的where条件，在数据库中提取与应用浅析 。在这里，我直接给出分析后的结果：

• Index key：pubtime > 1 and puptime < 20。此条件，用于肯定SQL在idx_t1_pu索引上的查询范围。
• Index Filter：userid = ‘hdc’ 。此条件，能够在idx_t1_pu索引上进行过滤，但不属于Index Key。
• Table Filter：comment is not NULL。此条件，在idx_t1_pu索引上没法过滤，只能在聚簇索引上过滤。

在分析出SQL where条件的构成以后，再来看看这条SQL的加锁状况 (RR隔离级别)，以下图所示：

 

从图中能够看出，在Repeatable Read隔离级别下，由Index Key所肯定的范围，被加上了GAP锁；Index Filter锁给定的条件 (userid = ‘hdc’)什么时候过滤，视MySQL的版本而定，在MySQL 5.6版本以前，不支持Index Condition Pushdown(ICP)，所以Index Filter在MySQL Server层过滤，在5.6后支持了Index Condition Pushdown，则在index上过滤。若不支持ICP，不知足Index Filter的记录，也须要加上记录X锁，若支持ICP，则不知足Index Filter的记录，无需加记录X锁 (图中，用红色箭头标出的X锁，是否要加，视是否支持ICP而定)；而Table Filter对应的过滤条件，则在聚簇索引中读取后，在MySQL Server层面过滤，所以聚簇索引上也须要X锁。最后，选取出了一条知足条件的记录[8,hdc,d,5,good]，可是加锁的数量，要远远大于知足条件的记录数量。

结论：在Repeatable Read隔离级别下，针对一个复杂的SQL，首先须要提取其where条件。Index Key肯定的范围，须要加上GAP锁；Index Filter过滤条件，视MySQL版本是否支持ICP，若支持ICP，则不知足Index Filter的记录，不加X锁，不然须要X锁；Table Filter过滤条件，不管是否知足，都须要加X锁。