mvcc原理

MVCC

mvcc

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

MySQL的大多数事务型存储引擎实现的其实都不是简单的行级锁。基于提升并发性能的考虑, 它们一般都同时实现了多版本并发控制(MVCC)。不仅是MySQL, 包括Oracle,PostgreSQL等其他数据库系统也都实现了MVCC, 但各自的实现机制不尽相同, 因为MVCC没有一个统一的实现标准。

可以认为MVCC是行级锁的一个变种, 但是它在很多情况下避免了加锁操作, 因此开销更低。虽然实现机制有所不同, 但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC的实现方式有多种, 典型的有乐观(optimistic)并发控制 和 悲观(pessimistic)并发控制。

MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别够和MVCC不兼容, 因为 READ UNCOMMITTED 总是读取最新的数据行, 而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。

MVCC的实现依赖于：三个隐藏字段、Undo log和Read View

隐藏列

MySQL中会为每一行记录生成隐藏列，接下来就让我们了解一下这几个隐藏列吧。

（1）DB_TRX_ID：事务ID，是根据事务产生时间顺序自动递增的，是独一无二的。如果某个事务执行过程中对该记录执行了增、删、改操作，那么InnoDB存储引擎就会记录下该条事务的id。

（2）DB_ROLL_PTR：回滚指针，本质上就是一个指向记录对应的undo log的一个指针，大小为 7 个字节，InnoDB 便是通过这个指针找到之前版本的数据。该行记录上所有旧版本，在undo log中都通过链表的形式组织。

（3）DB_ROW_ID：行标识（隐藏单调自增 ID），如果表没有主键，InnoDB 会自动生成一个隐藏主键，大小为 6 字节。如果数据表没有设置主键，会以它产生聚簇索引。

undo log

每当我们要对一条记录做改动时（这里的改动可以指INSERT、DELETE、UPDATE），都需要把回滚时所需的东西记录下来, 比如:

Insert undo log ：插入一条记录时，至少要把这条记录的主键值记下来，之后回滚的时候只需要把这个主键值对应的记录删掉就好了。

Delete undo log：删除一条记录时，至少要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了。

Update undo log：修改一条记录时，至少要把修改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录更新为旧值就好了。InnoDB把这些为了回滚而记录的这些东西称之为undo log。这里需要注意的一点是，由于查询操作（SELECT）并不会修改任何用户记录，所以在查询操作执行时，并不需要记录相应的undo log。

每次对记录进行改动都会记录一条undo日志，每条undo日志也都有一个DB_ROLL_PTR属性，可以将这些undo日志都连起来，串成一个链表，形成版本链。版本链的头节点就是当前记录最新的值。

Read View

在可重复读隔离级别下，我们可以把每一次普通的select查询（不加for update语句）当作一次快照读，而快照便是进行select的那一刻，生成的当前数据库系统中所有未提交的事务id数组（数组里最小的id为min_id）和已经创建的最大事务id（max_id）的集合，即我们所说的一致性视图readview。在进行快照读的过程中要根据一定的规则将版本链中每个版本的事务id与readview进行匹配查询我们需要的结果。

快照读是不会看到别的事务插入的数据的。因此，幻读在“当前读”下才会出现。快照读的实现是基于多版本并发控制，即MVCC，可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。MVCC只在 READ COMMITTED 和 REPEATABLE READ两个隔离级别下工作，其他两个隔离级别不和MVCC不兼容。因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行，而SERIALIZABLE 则会对所有读取的行都加锁。事务的快照时间点（即下文中说到的Read View的生成时间）是以第一个select来确认的。所以即便事务先开始，但是select在后面的事务的update之类的语句后进行，那么它是可以获取前面的事务的对应的数据。

对于使用RC和RR隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的。核心问题就是：需要判断一下版本链中的哪个版本是当前事务可见的。为此，InnoDB提出了一个Read View的概念。

Read View就是事务进行快照读（普通select查询）操作的时候生产的一致性读视图，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，它由执行查询时所有未提交的事务id数组（数组里最小的id为min_id）和已经创建的最大事务id（max_id）组成，查询的数据结果需要跟read view做对比从而得到快照结果。

快照规则

版本链比对规则：

如果落在绿色部分（trx_id<min_id），表示这个版本是已经提交的事务生成的，这个数据是可见的；

如果落在红色部分（trx_id>max_id），表示这个版本是由将来启动的事务生成的，是肯定不可见的；

如果落在黄色部分（min_id<=trx_id<=max_id），那就包含两种情况：

a.若row的trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见；

b.若row的trx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见。

演示：

当我们执行到第一个select的语句时，会生成readview[100,200],300,

[100,200] : 未提交事务数组

300：已创建的最大事务id

分析：

1.第一个查询，当前事务id:300 ,落在黄色区域，是可见的，所以结果：马云01

2.第二个查询，当前事务id：100 ,落在黄色区域，数据在未提交的数组中，所以不可见

就需要往前一个版本找，前一个版本事务Id:100,落在黄色区域，所以也是不可见的，

接着往前找，数据不在未提交的数组中，所以可见，  结果：马云01

3.第三个查询，因为是InnoDB的RR模式，所以readview不会更改，仍为readview[100,200],300 当前事务id:200,落在黄色区域，数据在未提交数组中，所以不可见，需要往前一个版本找，同第二个查询，一直到找到事务id：300    结果：马云01

再来看一种情况：

如果重新开启一个查询

这个时候 事务100 300 都提交了，所以活跃事务数组中只有【200】  readView [200] 300

查询时：事务id ：200  落在黄色区域，在数组中，不可见，往前找 找到100 时，在绿色区域 可见

所以结果  ：马云03

InnoDB下的RC模式，上文中提到的RC模式的数据读都是读最新的即当前读，所以readview是实时生成的

当执行到查询的时候，readView[200] 300  所以结果同样为 马云03

show global variables like '%isolation%';

set global transaction_isolation ='read-committed';

set global transaction_isolation ='repeatable-read';

Uodo log 什么时候删除：

系统会判断，没有比这个undo log更早的read view的时候，undo log会被删除。所以这里也就是为什么我们建议你尽量不要使用长事务的原因。长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间