MVCC原理

看一遍就理解：MVCC原理详解 - 知乎 (zhihu.com)

全网最全的一篇数据库MVCC详解，不全我负责-mysql教程-PHP中文网

MVCC全称Multi-Version Concurrency Control，即多版本并发控制。指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程，这样子可以使不同事务在不加锁的情况下的读-写、写-读操作并发执行，从而提升系统性能。

MVCC实现的关键知识点

1.快照读和当前读

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

select * from core_user where id > 2;

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

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

• select lock in share mode (共享锁)
• select for update (排他锁)
• update (排他锁)
• insert (排他锁)
• delete (排他锁)
• 串行化事务隔离级别

2.事务版本号

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

3.隐式字段

对于InnoDB存储引擎，每一行记录都有两个隐藏列trx_id（事务版本号）、roll_pointer（回滚指针），如果表中没有主键和非NULL唯一键时，则还会有第三个隐藏的主键列row_id

4.undo log

undo log，回滚日志，用于记录数据被修改前的信息。在表记录修改之前，会先把数据拷贝到undo log里，如果事务回滚，即可以通过undo log来还原数据。

作用：

1. 事务回滚时，保证原子性和一致性。
2. 用于MVCC快照读。

5.版本链

多个事务并行操作某一行数据时，不同事务对该行数据的修改会产生多个版本，然后通过回滚指针（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数据地址。

6.Read View

Read View是事务执行SQL语句时，产生的读视图。实际上在innodb中，每个SQL语句执行前都会得到一个Read View。

它主要是用来做可见性判断的，即判断当前事务可见哪个版本的数据

  Read view 的几个重要属性

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

Read view 匹配条件规则如下：

1. 如果数据事务ID trx_id < min_limit_id，表明生成该版本的事务在生成Read View前，已经提交(因为事务ID是递增的)，所以该版本可以被当前事务访问。
2. 如果trx_id>= max_limit_id，表明生成该版本的事务在生成ReadView后才生成，所以该版本不可以被当前事务访问。
3. 如果 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生成之前就已经提交了，修改的结果，当前事务是能看见的。

MVCC实现原理 

1.查询一条记录，基于MVCC，是怎样的流程

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

InnoDB 实现MVCC，是通过Read View+ Undo Log 实现的，Undo Log 保存了历史快照，Read View可见性规则帮助判断当前版本的数据是否可见。

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

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

隔离级别设置为读已提交（RC），事务A和事务B同时对core_user表进行查询和修改操作。

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

执行流程如下：

最后事务A查询到的结果是，name=曹操的记录，我们基于MVCC，来分析一下执行流程：

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

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

(3).事务A生成一个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

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

从图可得，最新版本的列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隔离级别，存在不可重复读并发问题。

3. 可重复读（RR）隔离级别，解决不可重复读问题的分析

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

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

还是这个事务A和事务B，如下：

 

然后执行第2个查询的时候：

事务A再次执行查询操作，复用老的Read View副本，Read View对应的值如下

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

 

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

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

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

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

所以，trx_id=100这个记录，对于当前事务是可见的，所以两次查询结果，都是name=孙权的那个记录。即在可重复读（RR）隔离级别下，复用老的Read View副本，解决了不可重复读的问题。

4.MVCC是否解决了幻读问题呢？

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

（1）RR级别下，一个快照读的例子，不存在幻读问题

由图可得，步骤2和步骤6查询结果集没有变化，看起来RR级别是已经解决幻读问题啦~

 （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隔离级别解决了幻读问题？）

（3）这种特殊场景，似乎有幻读问题

其实，上图事务A中，多加了update account set balance=200 where id=5;这步操作，同一个事务，相同的sql，查出的结果集不同了，这个结果，就符合了幻读的定义~

• 解决幻读问题

快照读：通过MVCC来进行控制的，不用加锁。按照MVCC中规定的“语法”进行增删改查等操作，以避免幻读。

当前读：通过next-key锁（行锁+gap锁）来解决问题的。