MVCC（多版本并发控制）

事务中，隔离性是如何保证的呢？

1、排他锁（当一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁）

2、mvcc（多版本并发控制）

MVCC

全称 Multi-Version Concurrency Control ，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突

MVCC的具体实现，主要依赖于数据库记录中的：隐式字段、undo log日志、readView。

数据库的每一行，都有三个隐藏字段：DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID

DB_TRX_ID :是自增的

mvcc主要依赖隐藏的字段是前两个，也就是：最近修改事务id，和回滚指针

undo log ：回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志

当insert一条数据时，产生的undo log日志只在回滚时需要，在事务提交后，可立即被删除

在update、delete的时候，产生的undo log日志不仅在回滚时需要，mvcc版本访问也需要，不会立即被删除

如图所示：

1、当最初insert一条数据时，会生成一个自增的事务id，同时回滚指针指向是null；因为这就是第一版，没有上一版

2、事务2，修改age为3，则将上一个版本（也就是最初insert的一版）保存到undo log中，最近修改事务id自增为2（打个比方为2，实际上不是int类型的自增）

回滚指针，指向的是undo log日志中上一个版本，age为30的那个版本的内存地址

3、事务3，修改name为A3，则将事务2修改的那个版本（age为3的版本）也保存到undo log日志中，同时当前事务3提交的这一版最近修改事务id同样自增；

回滚指针，指向事务2所修改的那个版本在undo log中的位置

4、事务4，修改age为10，则将事务3修改的那个版本（name=A3的版本）保存到undo log日志中，同时当前事务4提交的这一版最近修改事务id同样自增；

回滚指针，指向事务3所修改的那个版本在undo log中的位置

以此类推，每次update，delete的之前那些版本，会将保存到undo log中，不会立马删除，以便回滚和mvcc使用

版本链：多个事务并行操作某一行记录，记录不同事务修改数据的版本，通过roll_pointer（隐藏字段DB_ROLL_PTR）回滚指针，指向上一个版本的数据，形成一个链表

readView（读视图）是"快照读"SQL执行时，mvcc提供数据的依据，记录并维护当前活跃的事务id（也就是尚未提交的事务id）

根据ReadView的匹配规则，和当前一些事务id，判断该访问那个版本的数据

当前读：

读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select ... lock in share mode（共享锁），

select ... for update、update、insert、delete（排他锁）都是一种当前读

快照读：

简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。

Read Committed（RC：读已提交）：每次select，都生成一个快照读。

Repeatable Read（RR：可重复读）：开启事务后第一个select语句才是快照读的地方。

当事务5开启，尝试两次读取id为30的表记录时

m_ids：包含3、4、5三个活跃的事务，都还没有提交

min_trx_id：最小活跃事务，显然是事务3

max_trx_id：预分配事务id，是最大活跃事务+1，那么就是事务6（预分配的事务id）

creator_trx_id：ReadView这个读视图创建者的事务id，那就是事务5

不同的隔离级别，生成ReadView的时机不同：

1、Read Committed：读已提交，在事务中每一次执行快照读时，都会生成一个ReadView读视图

简而言之，RC隔离级别，事务每次读取的都是上一次已提交的数据版本

2、Repeatable Read：可重复读，仅在事务中第一次执行快照读时生成ReadView读视图，后续这个事务，每次读都复用这个ReadView

RR级别，事务每次读取的，都是第一次读取之前的最近的一次提交记录，后面每次读取，都直接读这个版本