MYSQL的MVCC到底是什么?(荣耀典藏版)-优快云博客

MVCC
MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

多版本控制: 指的是一种提高并发的技术。最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了InnoDB的并发度。在内部实现中，与Postgres在数据行上实现多版本不同，InnoDB是在undolog中实现的，通过undolog可以找回数据的历史版本。找回的数据历史版本可以提供给用户读(按照隔离级别的定义，有些读请求只能看到比较老的数据版本)，也可以在回滚的时候覆盖数据页上的数据。在InnoDB内部中，会记录一个全局的活跃读写事务数组，其主要用来判断事务的可见性。
MVCC是一种多版本并发控制机制。

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

二、什么是mysql事务？

Mysql事务（Transaction）用于保证数据的一致性，事务是在数据库管理系统中执行的一个逻辑操作单元，它是由一组列数据库操作组成的逻辑工作单元。

这一组操作要么全部成功，要么全部失败，不存在部分成功部分失败的情况，所有的操作共进退，因此事务是一个不可分割的逻辑单元，举个案例(来自)。

   现在A、B发生了转账行为（假设都有10w元，小明给小红转账10w元）
    -- 从A账户减去5w元
    UPDATE account SET money = money - 50000 WHERE name = "A";
    -- 小红对应的账户增加100元
    UPDATE account SET money = money + 50000  WHERE name = "B";
    -- 说明：
    上面的2条SQL可以被认为是一个事务
   其中有任何一条SQL语句执行错误或系统宕机都会导致数据恢复到最初执行这两条语句前(ROLLBACK)
    但是这两条SQL都执行成功的话则会提交事务(COMMIT)

三、事务解决了什么问题？

在原来没有事务的情况下，当多个用户同时执行对同一条数据的操作时，就会涉及到冲突问题。

比如，如果用户A在进行修改，而此时用户B也要进行修改，那么就可能会导致数据混乱或者损坏

通过使用事务，可以确保数据的准确性和完整性，还可以减少数据库故障对业务系统的影响，提高了系统的可用性和稳定性。

四、事务特性

事务有ACID四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），实现事务须遵守这四个特性。

4.1.ACID

原子性（Atomicity）：事务是一个不可分割的操作单元，要么完全执行，要么完全不执行。如果事务中的某个操作失败，那么整个事务都将被撤销，回滚到事务开始前的状态。

一致性（Consistency）：事务在执行之前和执行之后，数据库的状态必须保持一致。这意味着事务执行过程中的任何变化都必须满足预定的规则和约束。

隔离性（Isolation）：事务的执行应该与其他事务的执行相互隔离，即每个事务的操作独立于其他事务的操作。这确保了事务在并发执行时，不会相互干扰导致数据不一致或异常结果。

持久性（Durability）：一旦事务被提交，其所做的更改将永久保存在数据库中，并且在系统故障或重启后仍然保持有效。

这么看ACID的概念可能不怎么好理解，这里举个栗子，加深下

4.2.ACID是如何保证的

MySQL事务的特性也是基于某些底层的功能来实现的，这些特性的实现如下：

• 【持久性】通过 redo log （重做日志）来保证的

• 【原子性】通过 undo log（回滚日志）来保证的

• 【隔离性】通过 MVCC（多版本并发控制+读写锁）来保证的

• 【一致性】则是通过持久性+原子性+隔离性来保证

4.3.基本使用

日常开发中我们可能更多的基于ORM来进行事务的操作，各有各的用法，我们来看看MySQL是如何使用事务的。

默认情况下，MySQL处于自动提交模式，即每个语句都被视为一个事务，并自动提交到数据库

START TRANSACTION; //或者 BEGIN 来开启一个新的事务

DML语句1；
DML语句2;

ROLLBACK; //事务回滚

COMMIT; //事务提交

也就是说在你执行了这个命令后，MySQL会将接下来的所有语句视为事务的一部分，直到你提交或者回滚事务。

而ROLLBACK将撤销事务中的所有更改，并且回滚到事务开始之前的状态。

COMMIT使事务的更改永久生效，并将它们保存到数据库中。

DML（Data Manipulation Language）语句：数据操纵语句，用于添加、删除、更新和查询数据库记录。

4.4.事务类型

MYSQL事务分为【隐式事务和显示事务】

隐式事务：

比如insert、update、delete语句，事务的开启、提交或回滚由mysql内部自动控制的，事务自动开启、提交或回滚。

我们可以通过 show variables like 'autocommit'查看是否开启了自动提交，autocommit为ON表示开启了自动提交

显示事务:

显式事务是指在应用程序中明确指定事务的开始和结束，使用BEGIN、COMMIT和ROLLBACK语句来控制事务的执行，语法如下：

BEGIN;
-- SQL statements
COMMIT;

五、多事务并发问题

我们知道在并发情况下和单线程处理问题的方式是不一样的，MySQL服务器支持多个Client进行连接，意味着存在多事务并发情况，同样在多事务并发情况下是存在脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题。

这几个问题我们一个个看，到底是什么现象

5.1.脏读

现象：在数据库访问中，一个事务读取了另一个事务未提交的数据，导致读取到的数据是不一致或者无效的，脏读一般是针对于update操作的。

5.2.不可重读

现象：不可重复读是指在一个事务内，多次读取同一数据，但是数据的值发生了改变

5.3.幻读

现象：幻读是一种数据库事务的并发问题，指的是在一个事务中，多次查询同一符合条件的的数据，出现了前后两次记录数量不一致的情况。

小结一下：

• 脏读：读到其他事务未提交的数据

• 不可重复读：前后两次读取的数据不一致

• 幻读：前后读取的记录数量不一致

大家弄懂了几个的区别吗？如果不太清楚的，可以结合事务隔离级别的案例流程来了解

六、事务隔离级别

既然多事务并发情况下会出现脏读、不可重复读、幻读的情况，那么这些该如何避免呢？

如果数据库进行隔离操作，就能减少问题的发生了，事务的隔离级别是指在并发事务中，一个事务对数据的修改是否对其他事务可见，

以及其他事务对数据的修改是否对当前事务可见。但是不同的隔离级别还是会导致不同的并发问题发生，但是能对这些现象进行规避。

不同的事务隔离级别对应的情况如下：

隔离水平高低排序如下，但是隔离级别越高，性能效率就越低。

不同的事务隔离级别在并发事务下也会产生不同的问题，如下图（脏读、不可重复读、幻读。

总结起来就是说：

• 【读未提交】隔离级别：可能发生脏读、不可重复读和幻读现象；

• 【读提交】隔离级别：可能发生不可重复读和幻读现象，但是不可能发生脏读现象；

• 【可重复读】隔离级别：可能发生幻读现象，但是不可能脏读和不可重复读现象；

• 【串行化】隔离级别：不会发生脏读、不可重复读和幻读现象

6.1.如何设置隔离级别

我们来验证MySQL默认的隔离级别是不是可重复读，可通过 show variables like 'transaction_isolation' 命令查。

// mysql 5.7之后查看隔离级别
show variables like 'transaction_isolation'; 

+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | REPEATABLE-READ |
+---------------+-----------------+

从上面的value值可以看出确实是可重复读，我们看下如何去修改隔离级别，两种方式：

1：可以在 MySQL 的配置文件 my.cnf、my.ini 中设置

比如设置为：transaction-isolation=REPEATABLE-READ # 可重复读

2：使用 SET TRANSACTION 命令改变单个或者所有新连接的事务隔离级别

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

比如：
set session transaction isolation level read committed;

• 不带 GLOBAL 或 SESSION 关键字表示设置下一个事务的隔离级别；
• 使用 GLOBAL 关键字表示对全局设置事务隔离级别，设置后的事务隔离级别对所有新的数据库连接生效；
• 使用 SESSION 关键字表示对当前的数据库连接设置事务隔离级别，只对当前连接生效；
• 任何客户端都可以自由改变当前会话的事务隔离级别，可以在事务中间改变，也可以改变下一个事务的隔离级别

6.2.分析不同的隔离级别

在数据库中新建测试表user，对于隔离级别的分析都基于user表进行，在分析不同的事务隔离级别额时候都会把问题先下结论，再进行场景分析。

// 表结构
CREATE TABLE `user` (
  `id` int NOT NULL AUTO_INCREMENT COMMENT '用户id',
  `name` varchar(32) COLLATE utf8_bin DEFAULT NULL COMMENT '姓名',
  `point` int DEFAULT '0' COMMENT '积分',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

//插入一条记录
INSERT INTO user (name, point) VALUES('xiaoxu', 100)

读未提交（read uncommitted）：问题（可能发生脏读、不可重复读和幻读现象）。

// 先将事务隔离级别设置为读未提交 read uncommitted
set session transaction isolation level read uncommitted;

现象解读

启动两个事务A、B，事务A查询到的值是100，然后进行Update将point设置为150，此时事务A未提交，而事务B查询的时候值是150。而此时事务B已经读取到150进行后续业务了，但是事务A混滚，事务B的数据就是脏数据了（脏读）

而如果一开始事务A查询的值是100，事务B进行Update了Point的值，改成200，事务A再查询的值就是200，事务B回滚后，造成了事务A两次读取结果不一致（不可重复度），这里就不再画图了。

而幻读这里同样解决不了

读已提交（read committed）：可能发生不可重复读和幻读现象。

// 同样先将事务隔离级别设置为读未提交 read committed
set session transaction isolation level read committed;

现象解读：

启动两个事务A、B，事务A查询到的值是100，此时事务B将point的值改为150（事务未提交），事务A查询到的值还是100，而事务B提交后，事务A查询到值是150。事务A相同条件下两次查询的结果不一致，虽然解决了脏读，但是没做到可重复读，同样没法解决幻读。

可重复读（repeatable read）：可能发生幻读现象

// 同样先将事务隔离级别设置为读未提交 repeatable read
set session transaction isolation level repeatable read;

现象解读

可重复读不会发生脏读和不可重复读问题，但是可能会发生幻读问题.

启动两个事务A、B，事务A查询到point > 50的记录得到一条记录，事务B查询到point > 50的记录也是一条记录，此时事务A插入一条point=150的记录，并提交事务，此时事务B再次查询point>50的记录，同样的条件，出现了两条记录。

这种和前一次读到的记录数量不一样了，就感觉发生了幻觉一样，这种现象就被称为幻读

串行化（serializable）：脏读、不可重复读和幻读现象都【不可能会发生】

串行化是4种事务隔离级别中隔离效果最好的，解决了脏读、可重复读、幻读的问题，但是效果最差，它将事务的执行变为顺序执行。

通过举例不同隔离级别发生的情况，想必大家对多事务并发问题和事务的隔离级别会比较清楚了哈，换个思路：不同的事务隔离级别是为了解决多事务并发可能发生的不同问题，这样理解起来更顺！

需要注意的是，InnoDB默认的事务隔离级别是【可重复读】，但是InnoDB在这一级别，在部分场景下规避了幻读的问题，接下来看一下两种解决方式。快照读普通select 语句：是基于MVCC 多版本并发控制方式解决了幻读当前读（select ... for update 等语句），是通过 next-key lock（记录锁+间隙锁）方式解决了幻读

6.3.快照读和当前读

MySQL读取数据实际上有两种模式，分别是当前读和快照读。

6.3.1.快照读

普通的select语句(不包括 select ... lock in share mode; select ... for update;)，也就是不加锁的select操作都是采用快照读的模式。MySQL使用MVCC (Multiversion Concurrency Control)机制来保证被读取到数据的一致性，读数据不需要进行加锁，不会被其他事务阻塞。

像不加锁的select操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC,可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

注：即使某个数据正在被修改或插入新数据的时候，也可以进行读取该数据，因为快照已生成，保证了读写不冲突。而不同隔离级别下，创建快照的时机也不同：

• read committed (读已提交)：事务每次select时创建ReadView。

• repeatable read (可重复读)：事务第一次select时创建ReadView，后续一直使用。

6.3.2.当前读

数据修改的操作(update、insert、delete) 都是采用当前读的模式，过对读取到的数据(索引记录)【加锁】来保证数据一致性，比如：

select ... lock in share mode; 
select ... for update; 
insert; update;
delete;

说白了MVCC就是为了实现读-写冲突不加锁，而这个读指的就是快照读, 而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现。

6.3.3.当前读，快照读和MVCC之间是什么关系呢？

准确的说，MVCC多版本并发控制指的是 “维持一个数据的多个版本，使得读写操作没有冲突” 这么一个概念。仅仅是一个理想概念。
而在MySQL中，实现这么一个MVCC理想概念，我们就需要MySQL提供具体的功能去实现它，而快照读就是MySQL为我们实现MVCC理想模型的其中一个具体非阻塞读功能。而相对而言，当前读就是悲观锁的具体功能实现。
要说的再细致一些，快照读本身也是一个抽象概念，再深入研究。MVCC模型在MySQL中的具体实现则是由 3个隐式字段，undo日志 ，Read View 等去完成的，具体可以看下面的MVCC实现原理。

ok、明白了吗？小编这下也补缺查漏的明白了。

七、MVCC多版本并发控制

7.1.解决了什么问题

多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题。

MVCC带来的好处是？

数据库并发场景有三种，分别为：

读-读：不存在任何问题，也不需要并发控制。
读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读。
写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失。

注意：第1类丢失更新：事务A撤销时，把已经提交的事务B的更新数据覆盖了；第2类丢失更新：事务A覆盖事务B已经提交的数据，造成事务B所做的操作丢失。

MVCC带来的好处是？
多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。所以MVCC可以为数据库解决以下问题

在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能。
同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题。

小结一下：
总之，MVCC就是因为大牛们，不满意只让数据库采用悲观锁这样性能不佳的形式去解决读-写冲突问题，而提出的解决方案，所以在数据库中，因为有了MVCC，所以我们可以形成两个组合：

MVCC + 悲观锁
MVCC解决读写冲突，悲观锁解决写写冲突。
MVCC + 乐观锁
MVCC解决读写冲突，乐观锁解决写写冲突。

7.2.如何实现的

实现原理主要是依赖记录中的三个隐式字段，undo日志，Read View 来实现的。

7.3.隐藏字段

InnoDB在每行数据都增加三个隐藏字段，一个唯一行号，一个记录创建的版本号，一个记录回滚的版本号，如下：

db_row_id：6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID生成一个聚簇索引。

db_trx_id：6byte，最近修改（修改、插入）事务ID：记录创建这条记录以及最后一次修改该记录的事务的ID，是一个指针。

db_roll_ptr：7byte，回滚指针，指向这条记录的上一个版本（上一个版本存储于，rollback segment里）。

实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了。

如上图，DB_ROW_ID是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID是当前操作该记录的事务ID,而DB_ROLL_PTR是一个回滚指针，用于配合undo日志，指向上一个旧版本。

7.4.Undo日志

undo log是为回滚而用，用于记录数据修改前的信息，需要注意的一点是，由于查询操作（SELECT）并不会修改任何用户记录，因此不需要记录相应的undo log。

不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，即版本链表

因为undo log 记录事务修改之前版本的数据信息，因此假如由于系统错误或者rollback操作而回滚的话可以根据undo log的信息来进行回滚到没被修改前的状态。

undo log主要分为两种：

insert undo log
代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃
update undo log
事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

purge

从前面的分析可以看出，为了实现InnoDB的MVCC机制，更新或者删除操作都只是设置一下老记录的deleted_bit，并不真正将过时的记录删除。

为了节省磁盘空间，InnoDB有专门的purge线程来清理deleted_bit为true的记录。为了不影响MVCC的正常工作，purge线程自己也维护了一个read view（这个read view相当于系统中最老活跃事务的read view）;如果某个记录的deleted_bit为true，并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的。

对MVCC有帮助的实质是update undo log ，undo log实际上就是存在rollback segment中旧记录链，它的执行流程如下：

比如一个有个事务插入persion表插入了一条新记录，记录如下，name为Jerry, age为24岁，隐式主键是1，事务ID和回滚指针，我们假设为NULL。

现在来了一个事务1对该记录的name做出了修改，改为Tom

在事务1修改该行(记录)数据时，数据库会先对该行加排他锁。
然后把该行数据拷贝到undo log中，作为旧记录，既在undo log中有当前行的拷贝副本。
拷贝完毕后，修改该行name为Tom，并且修改隐藏字段的事务ID为当前事务1的ID, 我们默认从1开始，之后递增，回滚指针指向拷贝到undo log的副本记录，既表示我的上一个版本就是它。
事务提交后，释放锁。

又来了个事务2修改person表的同一个记录，将age修改为30岁

在事务2修改该行数据时，数据库也先为该行加锁。
然后把该行数据拷贝到undo log中，作为旧记录，发现该行记录已经有undo log了，那么最新的旧数据作为链表的表头，插在该行记录的undo log最前面。
修改该行age为30岁，并且修改隐藏字段的事务ID为当前事务2的ID, 那就是2，回滚指针指向刚刚拷贝到undo log的副本记录。
事务提交，释放锁。

从上面，我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，既链表，undo log的链首就是最新的旧记录，链尾就是最早的旧记录（当然就像之前说的该undo log的节点可能是会purge线程清除掉，向图中的第一条insert undo log，其实在事务提交之后可能就被删除丢失了，不过这里为了演示，所以还放在这里）。

7.5.Read View - 读视图

什么是Read View？

Read View就是事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大)。

所以我们知道 Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

Read View遵循一个可见性算法，主要是将要被修改的数据的最新记录中的DB_TRX_ID（即当前事务ID）取出来，与系统当前其他活跃事务的ID去对比（由Read View维护），如果DB_TRX_ID跟Read View的属性做了某些比较，不符合可见性，那就通过DB_ROLL_PTR回滚指针去取出Undo Log中的DB_TRX_ID再比较，即遍历链表的DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的DB_TRX_ID, 那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本。

那么这个判断条件是什么呢？

如上，它是一段MySQL判断可见性的一段源码，即changes_visible方法（不完全哈，但能看出大致逻辑），该方法展示了我们拿DB_TRX_ID去跟Read View某些属性进行怎么样的比较

在展示之前，我先简化一下Read View，我们可以把Read View简单的理解成有三个全局属性

trx_list（名字我随便取的）
一个数值列表，用来维护Read View生成时刻系统正活跃的事务ID
up_limit_id
记录trx_list列表中事务ID最小的ID
low_limit_id
ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值+1

首先比较DB_TRX_ID < up_limit_id, 如果小于，则当前事务能看到DB_TRX_ID 所在的记录，如果大于等于进入下一个判断
接下来判断 DB_TRX_ID 大于等于 low_limit_id , 如果大于等于则代表DB_TRX_ID 所在的记录在Read View生成后才出现的，那对当前事务肯定不可见，如果小于则进入下一个判断
判断DB_TRX_ID 是否在活跃事务之中，trx_list.contains(DB_TRX_ID)，如果在，则代表我Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的；如果不在，则说明，你这个事务在Read View生成之前就已经Commit了，你修改的结果，我当前事务是能看见的

7.5.1.整体流程

我们在了解了隐式字段，undo log，以及Read View的概念之后，就可以来看看MVCC实现的整体流程是怎么样了

整体的流程是怎么样的呢？我们可以模拟一下

当事务2对某行数据执行了快照读，数据库为该行数据生成一个Read View读视图，假设当前事务ID为2，此时还有事务1和事务3在活跃中，事务4在事务2快照读前一刻提交更新了，所以Read View记录了系统当前活跃事务1，3的ID，维护在一个列表上，假设我们称为trx_list

事务1	事务2	事务3	事务4
事务开始	事务开始	事务开始	事务开始
…	…	…	修改且已提交
进行中	快照读	进行中
…	…	…

Read View不仅仅会通过一个列表trx_list来维护事务2执行快照读那刻系统正活跃的事务ID，还会有两个属性up_limit_id（记录trx_list列表中事务ID最小的ID），low_limit_id(记录trx_list列表中事务ID最大的ID，也有人说快照读那刻系统尚未分配的下一个事务ID也就是目前已出现过的事务ID的最大值+1，我更倾向于后者 >>>资料传送门 | 呵呵一笑百媚生的回答) ；所以在这里例子中up_limit_id就是1，low_limit_id就是4 + 1 = 5，trx_list集合的值是1,3，Read View如下图

我们的例子中，只有事务4修改过该行记录，并在事务2执行快照读前，就提交了事务，所以当前该行当前数据的undo log如下图所示；我们的事务2在快照读该行记录的时候，就会拿该行记录的DB_TRX_ID去跟up_limit_id,low_limit_id和活跃事务ID列表(trx_list)进行比较，判断当前事务2能看到该记录的版本是哪个。

所以先拿该记录DB_TRX_ID字段记录的事务ID 4去跟Read View的的up_limit_id比较，看4是否小于up_limit_id(1)，所以不符合条件，继续判断 4 是否大于等于 low_limit_id(5)，也不符合条件，最后判断4是否处于trx_list中的活跃事务, 最后发现事务ID为4的事务不在当前活跃事务列表中, 符合可见性条件，所以事务4修改后提交的最新结果对事务2快照读时是可见的，所以事务2能读到的最新数据记录是事务4所提交的版本，而事务4提交的版本也是全局角度上最新的版本。

ReadView中主要包含4个比较重要的内容，分别是：

creator_trx_id ，创建这个Read View 的事务ID，即创建者的事务ID，而不是记录中的trx_id哦！

说明：只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为0。

m_ids ：表示创建ReadView时当前系统中活跃的事务的ID集合 (“活跃"指的就是，启动了但还没提交)。

min_trx_id ：表示创建ReadView时活跃的事务中最小的事务 ID。

max_trx_id：表示创建ReadView时系统中应该分配给下一个事务的id值，当前最大事务ID+1

而判断数据记录可见性的逻辑就是通过readview和【行记录的隐藏字段trx_id】做对比的。

一个事务去访问记录的时候，怎么判断记录的可见性呢？

Read View决定当前事务能读到哪个版本的数据，从表记录到Undo Log历史数据的版本链，依次匹配，满足哪个版本的匹配规则，就能读到哪个版本的数据，一旦匹配成功就不再往下匹配。

遵循了以下可见性匹配规则：

规则说明：

• trx_id = creator_trx_id：如果 trx_id 值等于创建Read View的事务Id，那么数据记录的最后一次操作的事务就是当前事务，该版本的记录对当前事务可见。

• trx_id < min_trx_id：如果 trx_id 值小于 Read View 中的 min_trx_id ，表示这个版本的记录是在创建 Read View 前已经提交的事务生成的，所以该版本的记录对当前事务可见。

• trx_id >= max_trx_id：如果trx_id 值小于 Read View 中的 min_trx_id ，表示这个版本的记录是在创建 Read View 后才启动的事务生成的，所以该版本的记录对当前事务不可见。

• min_trx_id <= trx_id < max_trx*id：判断 *trx_id 是不是在当前事务ID集合（m_ids）里面

• 如果在m_ids中，则代表Read View生成时刻，这个事务还在活跃，还没有Commit，版本记录在前事务不可见。

• 如果不在m_ids中，则说明，这个事务在Read View生成之前就已经Commit了，版本记录在前事务可见。

好了，关于MVCC的介绍就讲完了，小伙伴们花点时间结合图多分析分析！

八、MVCC隔离级别分析

从前面我们也总结了，在不同的隔离级别下快照读生成的ReadView规则不同，区别如下：

read committed (读已提交)：事务每次select时创建ReadView，每个ReadView中四个字段的值都是不同的

repeatable read (可重复读)：事务第一次select时创建ReadView，后面都是复用这个ReadView

对这两者的分析继续使用文章开头的user表作为基础，就不多建其他表进行案例分析了

8.1.读已提交分析

来看示例流程，事务A，B几乎同事查询一条记录，因为是read committed (读已提交) 隔离级别，所以每次select都会生成不同的ReadView。

事务A、B查询流程图如下：

我们在来看事务ID分别为27和28的A、B读取trx_id 为 26 的记录，事务A进行了两次次查询，而第二次是在事务B提交之后，我们来两次次查询生成的ReadView的区别：

此时事务A能查询到point值为100，符合db_trx_id < min_trx_id规则，所以能查询到当前版本数据记录，但是第而次读之前事务B对进行了修改，并提交了事务，此时可见的版本链数据如下图：

此时表记录中的隐藏记录db_trx_id的值是28，符合规则 min_trx_id <= db_trx_id < maxtrxid（27<=28<29），并且当前数据版本的事务ID不在当前系统中活跃的事务m_ids集合，可以看到当前版本的数据，也就是能查询到 point的值是150。

因此整个过程中，同一个事务A内，相同的查询条件，查询到的数据不一致，也就是出现了不可重复读的情况。

8.2.可重复读分析

可重复读在事务第一次select时创建ReadView，后面都是复用这个ReadView，这个和读已提交的区别所在。

事务A、B的执行情况和读已提交的流程一样，都是针对同一条记录修改前后事务提交的两次查询，但是两次查询出来的都是一样的，值都是100。

但是两次查询的ReadView共用一个，结果如下：

可以看出符合规则规则 min_trx_id <= db_trx_id < max_trx_id（27<=27<29），并且当前数据版本的事务ID不在当前系统中活跃的事务m_ids集合，所以是不可以看到当前版本的数据，也就是为什么事务B提交了，但是第二次查询出来的point的值还是100。

所以通过这样的方式就实现了，就是通过复用原有ReadView的方式解决了重复读问题。

九、MVCC相关问题

9.1.RR是如何在RC级的基础上解决不可重复读的？

9.1.1.当前读和快照读在RR级别下的区别：

表1:

事务A	事务B
开启事务	开启事务
快照读(无影响)查询金额为500	快照读查询金额为500
更新金额为400
提交事务
	select `快照读`金额为500
	select lock in share mode`当前读`金额为400

在上表的顺序下，事务B的在事务A提交修改后的快照读是旧版本数据，而当前读是实时新数据400。

表2:

事务A	事务B
开启事务	开启事务
快照读（无影响）查询金额为500
更新金额为400
提交事务
	select `快照读`金额为400
	select lock in share mode`当前读`金额为400

而在表2这里的顺序中，事务B在事务A提交后的快照读和当前读都是实时的新数据400，这是为什么呢？

这里与上表的唯一区别仅仅是表1的事务B在事务A修改金额前快照读过一次金额数据，而表2的事务B在事务A修改金额前没有进行过快照读。

所以我们知道事务中快照读的结果是非常依赖该事务首次出现快照读的地方，即某个事务中首次出现快照读的地方非常关键，它有决定该事务后续快照读结果的能力

我们这里测试的是更新，同时删除和更新也是一样的，如果事务B的快照读是在事务A操作之后进行的，事务B的快照读也是能读取到最新的数据的

9.2.RC,RR级别下的InnoDB快照读有什么不同？

正是Read View生成时机的不同，从而造成RC,RR级别下快照读的结果的不同

在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可见；
即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见
而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因

总之在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。