MySQL-04-InnoDB存储引擎锁和加锁分析

      Latch一般称为闩锁(轻量级锁),因为其要求锁定的时间必须非常短。在InnoDB存储引擎中,latch又分为mutex(互斥量)和rwlock(读写锁)。
       Lock的对象是事务,用来锁定的是数据库中的对象,如表、页、行。并且一般lock的对象仅在事务commit或rollback后进行释放(不同的事务隔离级别释放时间可能不同)。

1-InnoDB存储引擎中的锁

共享锁(S Lock),允许事务读一行数据;
排他锁(X Lock),允许事务删除或更新一行数据

X锁和任何锁都不兼容,而S锁仅和S锁兼容  X锁和S锁都是行锁
兼容是指对同一记录(row)锁的兼容性情况

2-行锁的算法

InnoDB存储引擎有3种行锁算法,分别是:
Record Lock:单个行记录上的锁
Gap Lock:间隙锁,锁定一个范围,但不包含记录本身
Next-Key Lock:Gap Lock+ Record Lock,锁定一个范围,并且锁定记录本身
采用Next-Key Lock的锁定技术成为Next-Key Locking。其目的是为了解决幻读(phantom problem),其锁定不是单个值,而是一个范围,是谓词锁(predict lock)的一种改进。例如有一个索引有10,11,13,20这四个值,那么该索引可能被Next-Key Locking区间为(-∞,10]、(10,11]、(11,13]、(13,20]、(20,+ ∞)
InnoDB存储引擎的事务默认级别是RR,在该级别下,其采用Next-Key Locking的方式来加锁。而在RC级别下,其仅采用Record Lock。

开胃菜锁分析演示

CREATE TABLE `ta` (
  `a` int(10) NOT NULL,
  `b` int(10) NOT NULL,
  `c` int(10) NOT NULL,
  PRIMARY KEY (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into ta (a,b,c) values (1,3,4);
insert into ta (a,b,c) values (5,8,10);
insert into ta (a,b,c) values (10,12,13);

MySQL-04-InnoDB存储引擎锁和加锁分析_第1张图片

分析:表ta中有1,5,10三条记录,session1首先对a=5进行X锁定,由于a是主键,因此仅仅锁定5这个值,不是锁定范围,因此插入a=4不会阻塞。锁定由Next-Key Lock算法降级为Record Lock,提供应用的并发性。
如果a列是唯一索引,锁定由Next-Key Lock算法降级为Record Lock,提供应用的并发性

delete from ta where a=4;删除刚才插入的记录
ALTER TABLE `ta` ADD INDEX `index_b` (`b`) ;

MySQL-04-InnoDB存储引擎锁和加锁分析_第2张图片

执行如下5条语句:
(1)select * from ta where a=5 lock in share mode;
(2)insert into ta (a,b,c) values (4,7 ,44);
(3)insert into ta (a,b,c) values (6,11,44);
(4)insert into ta (a,b,c) values (6,12,44);
(5)insert into ta (a,b,c) values (20,3,44);
上面5条语句不能执行
解释:
b=8,查询到记录的主键是a=5,首先会锁定a=5的记录(X锁),所以第一条阻塞;由于索引b的值为3,8,12
该索引可能被Next-Key Locking区间为(-∞,3]、(3,8]、(8,12]、 (12,+ ∞)
虽然第二条第三条第四条第五条主键都不等于5,但是b的值在[3,12]范围内,因此都是阻塞的。

以下两条可以执行:是因为不满足a=5和b的区间[3,12]范围内。
insert into ta (a,b,c) values (100,2,44);
insert into ta (a,b,c) values (101,13,44);
 

3-加锁分析之大餐

MVCC:Snapshot Read vs Current Read
MySQL InnoDB存储引擎,实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注:与MVCC相对的,是基于锁的并发控制,Lock-Based Concurrency Control)。MVCC最大的好处,相信也是耳熟能详:读不加锁,读写不冲突。在读多写少的OLTP应用中,读写不冲突是非常重要的,极大的增加了系统的并发性能,这也是为什么现阶段,几乎所有的RDBMS,都支持了MVCC。
在MVCC并发控制中,读操作可以分成两类:快照读 (snapshot read)与当前读 (current read)。快照读,读取的是记录的可见版本 (有可能是历史版本),不用加锁。当前读,读取的是记录的最新版本,并且,当前读返回的记录,都会加上锁,保证其他事务不会再并发修改这条记录。
在一个支持MVCC并发控制的系统中,哪些读操作是快照读?哪些操作又是当前读呢?

以MySQL InnoDB为例
快照读:简单的select操作,属于快照读,不加锁。(当然,也有例外,下面会分析)
select * from table where ?;
当前读:特殊的读操作,插入/更新/删除操作,属于当前读,需要加锁。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert into table values (…);
update table set ? where ?;
delete from table where ?;
所有以上的语句,都属于当前读,读取记录的最新版本。并且,读取之后,还需要保证其他并发事务不能修改当前记录,对读取记录加锁。其中,除了第一条语句,对读取记录加S锁 (共享锁)外,其他的操作,都加的是X锁 (排它锁)。

场景准备:

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

SQL1:select操作均不加锁,采用的是快照读,因此在下面的讨论中就忽略了,
主要讨论SQL2:delete操作的加锁。

所有的加锁分析必须提前告知:隔离级别和表的字段的索引情况(主键,唯一索引,普通索引还是普通字段没有索引),一切不以这些前提的分析都是瞎扯,一切不以这些前提的分析都是瞎扯,一切不以这些前提的分析都是瞎扯。


3.1-RC+id主键

delete from t1 where id = 10;// 只需要将主键上,id = 10的记录加上X锁即可。

表结构:t1(id primary key,name)

MySQL-04-InnoDB存储引擎锁和加锁分析_第3张图片

结论:id是主键时,此SQL只需要在id=10这条记录上加X锁即可。

3.2-RC+id唯一索引

表结构:t1(name primary key,id unique key)

MySQL-04-InnoDB存储引擎锁和加锁分析_第4张图片

       此组合中,id是unique索引,而主键是name列。此时,加锁的情况由于组合一有所不同。由于id是unique索引,因此delete语句会选择走id列的索引进行where条件的过滤,在找到id=10的记录后,首先会将unique索引上的id=10索引记录加上X锁,同时,会根据读取到的name列,回主键索引(聚簇索引),然后将聚簇索引上的name = ‘c’ 对应的主键索引项加X锁。为什么聚簇索引上的记录也要加锁?试想一下,如果并发的一个SQL,是通过主键索引来更新:update t1 set id = 100 where name = ‘c’; 此时,如果delete语句没有将主键索引上的记录加锁,那么并发的update就会感知不到delete语句的存在,违背了同一记录上的更新/删除需要串行执行的约束。

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

3.3-RC+id非唯一索引

  表结构:t1(name primary key,id key)

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

MySQL-04-InnoDB存储引擎锁和加锁分析_第5张图片

     

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

      结论:若id列上有非唯一索引,那么对应的所有满足SQL查询条件的记录,都会被加锁。同时,这些记录在主键索引上的记录,也会被加锁。

3.4-RC+id无索引

表结构:t1(name primary key,id)

      相对于前面三个组合,这是一个比较特殊的情况。id列上没有索引,where id = 10;这个过滤条件,没法通过索引进行过滤,那么只能走全表扫描做过滤。对应于这个组合,SQL会加什么锁?或者是换句话说,全表扫描时,会加什么锁?这个答案也有很多:有人说会在表上加X锁;有人说会将聚簇索引上,选择出来的id = 10;的记录加上X锁。那么实际情况呢?请看下图:

MySQL-04-InnoDB存储引擎锁和加锁分析_第6张图片

      由于id列上没有索引,因此只能走聚簇索引,进行全部扫描。从图中可以看到,满足删除条件的记录有两条,但是,聚簇索引上所有的记录,都被加上了X锁。无论记录是否满足条件,全部被加上X锁。既不是加表锁,也不是在满足条件的记录上加行锁。

      有人可能会问?为什么不是只在满足条件的记录上加锁呢?这是由于MySQL的实现决定的。如果一个条件无法通过索引快速过滤,那么存储引擎层面就会将所有记录加锁后返回,然后由MySQL Server层进行过滤。因此也就把所有的记录,都锁上了。

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

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

3.5-RR+id主键

加锁同3.1

3.6-RR+id唯一索引

加锁同3.2

3.7-RR+id非唯一索引

表结构:t1(name primary key,id key)

      RC隔离级别允许幻读,而RR隔离级别,不允许存在幻读。但是在组合五、组合六中,加锁行为又是与RC下的加锁行为完全一致。那么RR隔离级别下,如何防止幻读呢?问题的答案,就在组合七中揭晓。

      组合七,Repeatable Read隔离级别,id上有一个非唯一索引,执行delete from t1 where id = 10; 假设选择id列上的索引进行条件过滤,最后的加锁行为,是怎么样的呢?

MySQL-04-InnoDB存储引擎锁和加锁分析_第7张图片

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

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

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

       如图中所示,有哪些位置可以插入新的满足条件的项 (id = 10),考虑到B+树索引的有序性,满足条件的项一定是连续存放的。记录[5,e]之前,不会插入id=10的记录;[5,e]与[10,c]间可以插入[10, aa];[10,c]与[10,a]间,可以插入新的[10,bb],[10,cc]等;[10,a]与[20,b]间可以插入满足条件的[10,ee],[10,zz]等;而[20,b]之后也不会插入满足条件的记录。因此,为了保证[5,e]与[10,c]间,[10,c]与[10,a]间,[10,a]与[20,b]不会插入新的满足条件的记录,MySQL选择了用GAP锁,将这三个GAP给锁起来。

      Insert操作,如insert [10,d],首先会定位到[5,e]与[10,c]间,然后在插入前,会检查这个GAP是否已经被锁上,如果被锁上,则Insert不能插入记录。因此,通过第一遍的当前读,不仅将满足条件的记录锁上 (X锁),与组合三类似。同时还是增加3把GAP锁,将可能插入满足条件记录的3个GAP给锁上,保证后续的Insert不能插入新的id=10的记录,也就杜绝了同一事务的第二次当前读,出现幻象的情况。

有心的朋友看到这儿,可以会问:既然防止幻读,需要靠GAP锁的保护,为什么组合五、组合六,也是RR隔离级别,却不需要加GAP锁呢?

首先,这是一个好问题。其次,回答这个问题,也很简单。GAP锁的目的,是为了防止同一事务的两次当前读,出现幻读的情况。而组合五,id是主键;组合六,id是unique键,都能够保证唯一性。一个等值查询,最多只能返回一条记录,而且新的相同取值的记录,一定不会在新插入进来,因此也就避免了GAP锁的使用。

     结论:Repeatable Read隔离级别下,id列上有一个非唯一索引,对应SQL:delete from t1 where id = 10; 首先,通过id索引定位到第一条满足查询条件的记录,加记录上的X锁,加GAP上的GAP锁,然后加主键聚簇索引上的记录X锁,然后返回;然后读取下一条,重复进行。直至进行到第一条不满足条件的记录[20,b],此时,不需要加记录X锁,但是仍旧需要加GAP锁,最后返回结束。

3.8-RR+id无索引

     Repeatable Read隔离级别下的最后一种情况,id列上没有索引。此时SQL:delete from t1 where id = 10; 没有其他的路径可以选择,只能进行全表扫描。

表结构:t1(name primary key,id)

MySQL-04-InnoDB存储引擎锁和加锁分析_第8张图片

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

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

       当然,跟组合四:[id无索引, Read Committed]类似,这个情况下,MySQL也做了一些优化,就是所谓的semi-consistent read。semi-consistent read开启的情况下,对于不满足查询条件的记录,MySQL会提前放锁。针对上面的这个用例,就是除了记录[a,10],[c,10]之外,所有的记录锁都会被释放,同时不加GAP锁。semi-consistent read如何触发:要么是read committed隔离级别;要么是Repeatable Read隔离级别,同时设置了 innodb_locks_unsafe_for_binlog 参数。

      结论:在Repeatable Read隔离级别下,如果进行全表扫描的当前读,那么会锁上表中的所有记录,同时会锁上聚簇索引内的所有GAP,杜绝所有的并发 更新/删除/插入 操作。当然,也可以通过触发semi-consistent read,来缓解加锁开销与并发影响,但是semi-consistent read本身也会带来其他问题,不建议使用。

3.9-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隔离级别,读不加锁就不再成立,所有的读操作,都是当前读。

你可能感兴趣的:(mysql,mysql,数据库,InnoDB存储引擎锁)