MVCC详解

MVCC面试经典问题

1. 什么是快照读和当前读？
2. 了解MVCC吗？说下什么是MVCC?
3. MVCC的实现原理？有什么好处？
4. RC和RR级别下MVCC的差异？
   （在最后作出解答。。）

MVCC实现的核心知识：

1. 事务版本号：
   每次事务开启前都会从数据库获得一个自增长的事务ID，可以从事务ID判断事务的执行先后顺序。
2. 表格隐藏列
   trx_id ：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的 事务id 赋值给 trx_id 隐藏列。
   roll_pointer ：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到 undo日志 中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。
3. Undo log
   Undo log主要用于记录数据被修改之前的日志，在表信息修改之前先会把数据拷贝到undo log中，当事务进行回滚操作是可以通过undo log里的日志进行数据还原。
   用于MVCC快照读的数据，在MVCC多版本控制中，通过读取undo log的历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据版本。
4. 每次对记录进行改动，都会记录一条 undo日志 ，每条 undo日志 也都有一个 roll_pointer 属性（ INSERT 操作对应的 undo日志 没有该属性，因为该记录并没有更早的版本），可以将这些 undo日志 都连起来，串成一个链表，所以现在的情况就像下图一样：
   
5. ReadView
   在innodb 中每个事务开启后都会得到一个read_view。副本主要保存了当前数据库系统中正处于活跃（没有commit）的事务的ID号，其实简单的说这个副本中保存的是系统中当前不应该被本事务看到的其他事务id列表。
   ReadView中有几个重要的属性：
   m_ids ：表示在生成 ReadView 时当前系统中活跃的读写事务的 事务id 列表。（通俗来说：活跃的事务指的就是没有提交的事务）
   min_trx_id ：表示在生成 ReadView 时当前系统中活跃的读写事务中最小的 事务id ，也就是 m_ids 中的最
   小值。
   max_trx_id ：表示生成 ReadView 时系统中应该分配给下一个事务的 id 值。
   creator_trx_id ：表示生成该 ReadView 的事务的 事务id 。
6. ReadView的匹配条件：

• 如果被访问版本的 trx_id 属性值与 ReadView 中的 creator_trx_id 值相同，意味着当前事务在访问它自己
  修改过的记录，所以该版本可以被当前事务访问。
• 如果被访问版本的 trx_id 属性值小于 ReadView 中的 min_trx_id 值，表明生成该版本的事务在当前事务生
  成 ReadView 前已经提交，所以该版本可以被当前事务访问。
• 如果被访问版本的 trx_id 属性值大于 ReadView 中的 max_trx_id 值，表明生成该版本的事务在当前事务生
  成 ReadView 后才开启，所以该版本不可以被当前事务访问。
• 如果被访问版本的 trx_id 属性值在 ReadView 的 min_trx_id 和 max_trx_id 之间，那就需要判断一下
  trx_id 属性值是不是在 m_ids 列表中，如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该
  版本不可以被访问；如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

1. 什么是快照读和当前读？

当前读读取的是数据库记录，都是当前最新的版本，会对当前读取的数据进行加锁，防止其他事务修改数据。

快照读的实现就是基于多版本并发控制，即MVCC,既然是多版本，那么快照读读到的数据不一定是当前的最新的数据，有可能是之前历史版本的数据。

2.什么是MVCC？

MVCC(Multi-Version Concurrency Control)，多版本并发控制。MVCC是一种并发控制方法，通俗点就是MVCC通过保存数据的历史版本，根据比较版本号来处理数据的是否显示，从而达到读取数据的时候不需要加锁就可以保证事务隔离性的效果。mysql中的innoDB中就是使用这种方法来提高读写事务控制的、他大大提高了读写事务的并发性能，原因是MVCC是一种不采用锁来控制事物的方式，是一种非堵塞、同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题。

在从数据库中访问数据的时候，由于并发操作，可能会使读数据的人看到不一致的数据。要解决这样的问题最简单的方法就是加锁，让所有读者等待写者工作完成，但是这样做效率会很差。MVCC使用了一种不同的手段，每个连接到数据库的读者，在某个瞬间看到的是数据库的一个快照，写者写操作造成的变化在写操作完成之前（即数据库事务提交之前）对其他的读者是不可见的。

3.MVCC的实现原理？有什么好处？

转载：https://zhuanlan.zhihu.com/p/421769708

查询一条记录，基于MVCC，流程如下

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

读已提交（RC）隔离级别，存在不可重复读问题的分析历程

1. 创建core_user表，插入一条初始化数据,如下：

2. 隔离级别设置为读已提交（RC），事务A和事务B同时对core_user表进行查询和修改操作。
   
   最后事务A查询到的结果是，name=曹操的记录，我们基于MVCC，来分析一下执行流程：

(1). A开启事务，首先得到一个事务ID为100

(2).B开启事务，得到事务ID为101

(3).事务A生成一个Read View，read view对应的值如下

然后回到版本链：开始从版本链中挑选可见的记录：

版本链

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

min_limit_id(100)=<trx_id（100）<102; creator_trx_id = trx_id =100;
由此可得，trx_id=100的这个记录，当前事务是可见的。所以查到是name为孙权的记录。

（4). 事务B进行修改操作，把名字改为曹操。把原数据拷贝到undo log,然后对数据进行修改，标记事务ID和上一个数据版本在undo log的地址。

(5) 提交事务

(6) 事务A再次执行查询操作，新生成一个Read View，Read View对应的值如下

然后再次回到版本链：从版本链中挑选可见的记录：

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

min_limit_id(100)=<trx_id（101）<max_limit_id（102); 但是,trx_id=101，不属于m_ids集合
因此，trx_id=101这个记录，对于当前事务是可见的。所以SQL查询到的是name为曹操的记录。

综上所述，在读已提交（RC）隔离级别下，同一个事务里，两个相同的查询，读取同一条记录（id=1），却返回了不同的数据（第一次查出来是孙权，第二次查出来是曹操那条记录），因此RC隔离级别，存在不可重复读并发问题。

RC和RR级别下MVCC的差异？

生成ReadView的时机不同：

1. READ COMMITTED —— 每次读取数据前都生成一个ReadView（即每次执行select时会生成一个Readview）。
2. REPEATABLE READ —— 在第一次读取数据时生成一个ReadView。