MVCC- - 技术栈

文章目录

[1. 什么是MVCC](#1. 什么是MVCC)
[2. 快照读和当前读](#2. 快照读和当前读)
[3. 复习](#3. 复习)
[4. MVCC实现原理之ReadView](#4. MVCC实现原理之ReadView)
[5. 总结](#5. 总结)

文章目录

[1. 什么是MVCC](#1. 什么是MVCC)
[2. 快照读和当前读](#2. 快照读和当前读)
[3. 复习](#3. 复习)
[4. MVCC实现原理之ReadView](#4. MVCC实现原理之ReadView)
[5. 总结](#5. 总结)

1. 什么是MVCC

口述：MVCC其实他是解决这种读-写的情况的，当然读-写也可以用锁来实现，MVCC实现的话更加高效，用锁的话其实就是相当于串行的执行，读完才能写或者写完才能读。那MVCC其实它可以读写并存，就解决了读以提交和不可重复读的问题，其实MVCC在读的时候会生成readView这里的话其实对应不同隔离级别下生成的策略也是不同的，其实也是为了解决这个可不可以重复读和幻读问题的，要是在读已提交隔离级别下那么只要select就会生成readview，也正是因为这样，可能导致幻读，在可重复读隔离级别下，一个事务select只会生成一个select，所以这个时候只有第一个select会生成readview，readview里面又记录了当前活跃的事务id，那我之后再查询的事务也是以这个readview里面的活跃事务id为参考，然后再到undo log中去找，即使可能这个第一次到第二次的期间内有属于这个活跃事务列表中的事务进行了提交，但我认为你还是没有提交的，因为我的这个readview是根据第一次的select生成的，所以我在undo log 中一查，哎你的事务id在我的活跃列表中，你的操作可能会影响到我，我不读你，我再读当前undo log的前一个undo log，我再去判断，直到找到比这个活跃列表中的事务id小的那一条行记录，正因为这样，也就解决了幻读，不管一个事务有多少个select，我select到的和一个select的是一样的，不会存在select后发现怎么多了几行记录的情况。

在当前事务根据readView里面的信息去这条记录的回滚指针里面去找undo log，读到历史版本，其实这里的话就是比如select语句要执行时，innodb会将这个时刻系统中活跃的事务id记录到redaview中，因为当前读而这个时刻活跃的事务可能会影响自己，我正在读而你在修改还没提交，就会造成我的不可重复读和幻读，所以我吧这些东西记录在readview中，由readview记录的信息再去undo log中找属于我这个事务的历史版本。

2. 快照读和当前读

读取的是快照数据。不加锁的简单的 SELECT 都属于快照读，即不加锁的非阻塞读，快照读的实现是基于MVCC

对数据进行增删改都会进行当前读，都会加锁

3. 复习

在MySQL中，默认的隔离级别是可重复读，就可以解决幻读问题，使用的就是MVCC，

也是乐观锁体现。

隐藏字段、Undo Log版本链：

trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id隐藏列。
roll_pointer：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

4. MVCC实现原理之ReadView

MVCC 的实现依赖于：隐藏字段、Undo Log、Read View 。

Read View ：

如果一个事务想要查询这个行记录，需要读取哪个版本的行记录呢?这时就需要用到ReadView了

ReadView中的内容：

creator_trx_id，创建这个 Read View 的事务 ID。

说明：只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为 0 。
trx_ids，表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
up_limit_id，活跃的事务中最小的事务 ID。
low_limit_id，表示生成ReadView时系统中应该分配给下一个事务的id值。low_limit_id 是系统最大的事务id值，这里要注意是系统中的事务id，需要区别于正在活跃的事务ID。

ReadView的规则 ：
口述：其实就是判断undo log中记录的每个行记录的事务id是不是满足条件，就是undo log 中行的事务id要小于readView中记录的活动事务的范围，小于的话那其实就表示了我select的时候你这条记录以及commit了，因为活跃的事务就是记录当前select的时候系统中还有哪些事务在执行但是没有commit，那些事务就可能会影响自己，所以吧它们记录下来，根据比较规则从undo log中拿到版本记录。

5. 总结

MVCC是处理这种读-写、写-读情况下的一种方案

只在READ COMMITTD、REPEATABLE READ情况下

READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是生成ReadView的时机不同：

READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView
REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView就好了。

说明: 我们之前说执行DELETE语句或者更新主键的UPDATE语句并不会立即把对应的记录完全从页面中删除,而是执行一个所谓的delete mark操作，相当于只是对记录打上了一个删除标志位，这主要就是为MVCc服务的。因为可能要回滚，不能直接删除

通过MVCC我们可以解决:

读写之间阻塞的问题。通过MVCC可以让读写互相不阻塞，即读不阻塞写，写不阻塞读，这样就可以提升事务并发处理能力。
降低了死锁的概率。这是因为MVCC采用了乐观锁的方式，读取数据时并不需要加锁，对于写操作，也只锁定必要的行。
解决快照读的问题。当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的更新结果。