【数据库】MVCC原理详解

前言

MVCC实现原理是一道非常高频的面试题，最近技术讨论群的小伙伴不停在讨论，趁着五一假期有空，我们一起来聊聊。
1. 相干数据库知识点回顾

1.1 什么是数据库事件，为什么要有事件

事件，由一个有限的数据库操作序列构成，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。
   假如A转账给B 100 元，先从A的账户里扣除 100 元，再在 B 的账户上加上 100
元。如果扣完A的100元后，还没来得及给B加上，银行系统异常了，最后导致A的余额减少了，B的余额却没有增加。所以就需要事件，将A的钱回滚归去，就是这么简单。
  为什么要有事件呢？ 就是为了保证数据的最终一致性。
1.2 事件包括哪几个特性？

事件四个典型特性，即ACID，原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。

• 原子性：事件作为一个整体被执行，包含在其中的对数据库的操作要么全部都执行，要么都不执行。
  一致性：指在事件开始之前和事件竣事以后，数据不会被粉碎，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。
  
• 隔离性：多个事件并发访问时，事件之间是相互隔离的，一个事件不应该被其他事件干扰，多个并发事件之间要相互隔离。。
  
• 持久性：表示事件完成提交后，该事件对数据库所作的操作更改，将持久地生存在数据库之中。
  

1.3 事件并发存在的问题

事件并发会引起脏读、不可重复读、幻读问题。
1.3.1 脏读

如果一个事件读取到了另一个未提交事件修改过的数据，我们就称发生了脏读现象。
假设现在有两个事件A、B：

• 假设现在A的余额是100，事件A正在准备查询Jay的余额
  
• 事件B先扣减Jay的余额，扣了10，但是还没提交
  
• 最后A读到的余额是90，即扣减后的余额
  

由于事件A读取到事件B未提交的数据,这就是脏读。
1.3.2 不可重复读

同一个事件内，前后多次读取，读取到的数据内容不一致
假设现在有两个事件A和B：

• 事件A先查询Jay的余额，查到结果是100
  
• 这时间事件B 对Jay的账户余额进行扣减，扣去10后，提交事件
  
• 事件A再去查询Jay的账户余额发现变成了90
  

事件A被事件B干扰到了！在事件A范围内，两个雷同的查询，读取同一条记载，却返回了不同的数据，这就是不可重复读。
1.3.3 幻读

   如果一个事件先根据某些搜刮条件查询出一些记载，在该事件未提交时，另一个事件写入了一些符合那些搜刮条件的记载（如insert、delete、update），就意味着发生了幻读。
  假设现在有两个事件A、B：

• 事件A先查询id大于2的账户记载，得到记载id=2和id=3的两条记载
  
• 这时间，事件B开启，插入一条id=4的记载，而且提交了
  
• 事件A再去执行雷同的查询，却得到了id=2,3,4的3条记载了。
  

事件A查询一个范围的结果集，另一个并发事件B往这个范围中插入新的数据，并提交事件，然后事件A再次查询雷同的范围，两次读取到的结果集却不一样了，这就是幻读。
1.4 四大隔离级别

为相识决并发事件存在的脏读、不可重复读、幻读等问题，数据库大叔设计了四种隔离级别。分别是读未提交，读已提交，可重复读，串行化（Serializable）。
1.4.1 读未提交

读未提交隔离级别，只限制了两个数据不能同时修改，但是修改数据的时间，即使事件未提交，都是可以被别的事件读取到的，这级别的事件隔离有脏读、重复读、幻读的问题；
1.4.2 读已提交

读已提交隔离级别，当前事件只能读取到其他事件提交的数据，所以这种事件的隔离级别解决了脏读问题，但还是会存在重复读、幻读问题；
1.4 3 可重复读

可重复读隔离级别，限制了读取数据的时间，不可以进行修改，所以解决了重复读的问题，但是读取范围数据的时间，是可以插入数据，所以还会存在幻读问题；
1.4.4 串行化

事件最高的隔离级别，在该级别下，全部事件都是进行串行化顺序执行的。可以制止脏读、不可重复读与幻读全部并发问题。但是这种事件隔离级别下，事件执行很耗性能。
1.4.5 四大隔离级别，都会存在哪些并发问题呢

隔离级别脏读不可重复读幻读读未提交√√√读已提交×√√可重复读××√串行化××× 1.5 数据库是如何保证事件的隔离性的呢？

数据库是通过加锁，来实现事件的隔离性的。这就好像，如果你想一个人悄悄，不被别人打搅，你就可以在房门上加上一把锁。
加锁确实好使，可以保证隔离性。比如串行化隔离级别就是加锁实现的。但是频仍的加锁，导致读数据时，没办法修改，修改数据时，没办法读取，大大降低了数据库性能。
那么，如何解决加锁后的性能问题的？
答案就是,MVCC多版本并发控制！它实现读取数据不消加锁，可以让读取数据同时修改。修改数据时同时可读取。
2. 什么是 MVCC？

MVCC，即Multi-Version Concurrency Control （多版本并发控制）。它是一种并发控制的方法，一样平常在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事件内存。
   普通的讲，数据库中同时存在多个版本的数据，并不是整个数据库的多个版本，而是某一条记载的多个版本同时存在，在某个事件对其进行操作的时间，需要查察这一条记载的隐藏列事件版本id，比对事件id并根据事物隔离级别去判断读取哪个版本的数据。
  数据库隔离级别读已提交、可重复读 都是基于MVCC实现的，相对于加锁简单粗暴的方式，它用更好的方式去处理读写冲突，能有用提高数据库并发性能。
3. MVCC实现的关键知识点

3.1 事件版本号

   事件每次开启前，都会从数据库获得一个自增长的事件ID，可以从事件ID判断事件的执行先后顺序。这就是事件版本号。
  3.2 隐式字段

对于InnoDB存储引擎，每一行记载都有两个隐藏列trx_id、roll_pointer，如果表中没有主键和非NULL唯一键时，则还会有第三个隐藏的主键列row_id。
列名是否必须描述row_id否单调递增的行ID，不是必须的，占用6个字节。trx_id是记载操作该数据事件的事件IDroll_pointer是这个隐藏列就相当于一个指针，指向回滚段的undo日记 3.3 undo log

undo log，回滚日记，用于记载数据被修改前的信息。在表记载修改之前，会先把数据拷贝到undo log里，如果事件回滚，即可以通过undo log来还原数据。
可以这样以为，当delete一条记载时，undo log 中会记载一条对应的insert记载，当update一条记载时，它记载一条对应相反的update记载。
undo log有什么用途呢？

• 事件回滚时，保证原子性和一致性。
  
• 用于MVCC快照读。
  

3.4 版本链

多个事件并行操作某一行数据时，不同事件对该行数据的修改会产生多个版本，然后通过回滚指针（roll_pointer），连成一个链表，这个链表就称为版本链。如下：

其实，通过版本链，我们就可以看出事件版本号、表格隐藏的列和undo log它们之间的关系。我们再来小分析一下。

• 假设现在有一张core_user表，表里面有一条数据,id为1，名字为孙权：
  
  
  
  
• 现在开启一个事件A：对core_user表执行update core_user set name =“曹操” where id=1,会进行如下流程操作
  

• 首先获得一个事件ID=100
  
• 把core_user表修改前的数据,拷贝到undo log
  
• 修改core_user表中，id=1的数据，名字改为曹操
  
• 把修改后的数据事件Id=101改成当前事件版本号，并把roll_pointer指向undo log数据地址。
  
  
  
  

3.5 快照读和当前读

快照读： 读取的是记载数据的可见版本（有旧的版本）。不加锁,普通的select语句都是快照读,如：

1. select * from core_user where id > 2;

复制代码

当前读：读取的是记载数据的最新版本，显式加锁的都是当前读

1. select * from core_user where id > 2 for update;
2. select * from account where id>2 lock in share mode;

复制代码

3.6 Read View

• Read View是什么呢？ 它就是事件执行SQL语句时，产生的读视图。实际上在innodb中，每个SQL语句执行前都会得到一个Read View。
  
• Read View有什么用呢？ 它重要是用来做可见性判断的，即判断当前事件可见哪个版本的数据~
  

Read View是如何保证可见性判断的呢？我们先看看Read view 的几个重要属性

• m_ids:当前系统中那些生动(未提交)的读写事件ID, 它数据结构为一个List。
  
• min_limit_id:表示在生成Read View时，当前系统中生动的读写事件中最小的事件id，即m_ids中的最小值。
  
• max_limit_id:表示生成Read View时，系统中应该分配给下一个事件的id值。
  
• creator_trx_id: 创建当前Read View的事件ID
  

Read view 匹配条件规则如下：

• 如果数据事件ID trx_id < min_limit_id，表明生成该版本的事件在生成Read View前，已经提交(由于事件ID是递增的)，所以该版本可以被当前事件访问。
  
• 如果trx_id>= max_limit_id，表明生成该版本的事件在生成ReadView后才生成，所以该版本不可以被当前事件访问。
  
• 如果 min_limit_id =<trx_id< max_limit_id,需腰分3种环境讨论
  

   （1）.如果m_ids包含trx_id,则代表Read
View生成时刻，这个事件还未提交，但是如果数据的trx_id等于creator_trx_id的话，表明数据是自己生成的，因此是可见的。
（2）如果m_ids包含trx_id，而且trx_id不等于creator_trx_id，则Read
View生成时，事件未提交，而且不是自己生产的，所以当前事件也是看不见的；
（3）.如果m_ids不包含trx_id，则说明你这个事件在Read View生成之前就已经提交了，修改的结果，当前事件是能瞥见的。
  4. MVCC实现原理分析

4.1 查询一条记载，基于MVCC，是怎样的流程

• 获取事件自己的版本号，即事件ID
  
• 获取Read View
  
• 查询得到的数据，然后Read View中的事件版本号进行比力。
  
• 如果不符合Read View的可见性规则， 即就需要Undo log中历史快照;
  
• 最后返回符合规则的数据
  

InnoDB 实现MVCC，是通过Read View+ Undo Log 实现的，Undo Log 生存了历史快照，Read View可见性规则帮助判断当前版本的数据是否可见。
4.2 读已提交（RC）隔离级别，存在不可重复读问题的分析历程

• 创建core_user表，插入一条初始化数据,如下：
  
  
  
  
• 隔离级别设置为读已提交（RC），事件A和事件B同时对core_user表进行查询和修改操作。
  

1. 事务A: select * fom core_user where id=1
2. 事务B: update core_user set name =”曹操”

复制代码

执行流程如下：

最后事件A查询到的结果是，name=曹操的记载，我们基于MVCC，来分析一下执行流程：
(1). A开启事件，首先得到一个事件ID为100
(2).B开启事件，得到事件ID为101
(3).事件A生成一个Read View，read view对应的值如下
变量值m_ids100，101max_limit_id102min_limit_id100creator_trx_id100 然后回到版本链：开始从版本链中挑选可见的记载：

由图可以看出，最新版本的列name的内容是孙权，该版本的trx_id值为100。开始执行read view可见性规则校验：

1. min_limit_id(100)=<trx_id（100）<102;
2. creator_trx_id = trx_id =100;

复制代码

由此可得，trx_id=100的这个记载，当前事件是可见的。所以查到是name为孙权的记载。
（4). 事件B进行修改操作，把名字改为曹操。把原数据拷贝到undo log,然后对数据进行修改，标志事件ID和上一个数据版本在undo log的地址。

(5) 提交事件
(6) 事件A再次执行查询操作，新生成一个Read View，Read View对应的值如下
变量值m_ids100max_limit_id102min_limit_id100creator_trx_id100 然后再次回到版本链：从版本链中挑选可见的记载：

从图可得，最新版本的列name的内容是曹操，该版本的trx_id值为101。开始执行Read View可见性规则校验：

1. min_limit_id(100)=<trx_id（101）<max_limit_id（102);
2. 但是,trx_id=101，不属于m_ids集合

复制代码

因此，trx_id=101这个记载，对于当前事件是可见的。所以SQL查询到的是name为曹操的记载。
综上所述，在读已提交（RC）隔离级别下，同一个事件里，两个雷同的查询，读取同一条记载（id=1），却返回了不同的数据（第一次查出来是孙权，第二次查出来是曹操那条记载），因此RC隔离级别，存在不可重复读并发问题。
4.3 可重复读（RR）隔离级别，解决不可重复读问题的分析

在RR隔离级别下，是如何解决不可重复读问题的呢？我们一起再来看下，
还是4.2末节那个流程，还是这个事件A和事件B，如下：

4.3.1 不同隔离级别下，Read View的工作方式不同

实际上，各种事件隔离级别下的Read view工作方式，是不一样的，RR可以解决不可重复读问题，就是跟Read view工作方式有关。

• 在读已提交（RC）隔离级别下，同一个事件里面，每一次查询都会产生一个新的Read View副本，这样就可能造成同一个事件里前后读取数据可能不一致的问题（不可重复读并发问题）。
  

beginselect * from core_user where id =1生成一个Read View////select * from core_user where id =1生成一个Read View

• 在可重复读（RR）隔离级别下，一个事件里只会获取一次read view，都是副本共用的，从而保证每次查询的数据都是一样的。
  

beginselect * from core_user where id =1生成一个Read View//select * from core_user where id =1共用一个Read View副本 4.3.2 实例分析

我们穿越下，回到刚4.2的例子，然后执行第2个查询的时间：
事件A再次执行查询操作，复用老的Read View副本，Read View对应的值如下
变量值m_ids100，101max_limit_id102min_limit_id100creator_trx_id100 然后再次回到版本链：从版本链中挑选可见的记载：

从图可得，最新版本的列name的内容是曹操，该版本的trx_id值为101。开始执行read view可见性规则校验：

1. min_limit_id(100)=<trx_id（101）<max_limit_id（102);
2. 因为m_ids{100,101}包含trx_id（101），
3. 并且creator_trx_id (100) 不等于trx_id（101）

复制代码

所以，trx_id=101这个记载，对于当前事件是不可见的。这时间呢，版本链roll_pointer跳到下一个版本，trx_id=100这个记载，再次校验是否可见：

1. min_limit_id(100)=<trx_id（100）< max_limit_id（102);
2. 因为m_ids{100,101}包含trx_id（100），
3. 并且creator_trx_id (100) 等于trx_id（100）

复制代码

所以，trx_id=100这个记载，对于当前事件是可见的，所以两次查询结果，都是name=孙权的那个记载。即在可重复读（RR）隔离级别下，复用老的Read View副本，解决了不可重复读的问题。
4.4 网络江湖传说，MVCC是否解决了幻读问题呢？

网络江湖有个传说，说MVCC的RR隔离级别，解决了幻读问题，我们来一起分析一下。
4.4.1 RR级别下，一个快照读的例子，不存在幻读问题

由图可得，步调2和步调6查询结果集没有变革，看起来RR级别是已经解决幻读问题啦~
4.4.2 RR级别下，一个当前读的例子

假设现在有个account表，表中有4条数据，RR级别。
开启事件A，执行当前读，查询id>2的全部记载。
再开启事件B，插入id=5的一条数据。
流程如下：

显然，事件B执行插入操作时，壅闭了~由于事件A在执行select … lock in share mode（当前读）的时间，不但在id = 3,4 这2条记载上加了锁，而且在id > 2这个范围上也加了间隙锁。
因此，我们可以发现，RR隔离级别下，加锁的select, update, delete等语句，会使用间隙锁+ 临键锁，锁住索引记载之间的范围，制止范围间插入记载，以制止产生幻影行记载，那就是说RR隔离级别解决了幻读问题？
4.4.3 这种特殊场景，似乎有幻读问题

其实，上图事件A中，多加了update account set balance=200 where id=5;这步操作，同一个事件，雷同的sql，查出的结果集不同了，这个结果，就符合了幻读的界说~
这个问题，酷爱的朋侪，你觉得它算幻读问题吗，所以RR隔离级别，还是存在幻读问题吧？欢迎大家评论区留言哈。
参考资料

[1]数据库基础（四）Innodb MVCC实现原理: https://zhuanlan.zhihu.com/p/52977862

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。