Mysql(十二) MVCC并发版本控制

最新推荐文章于 2024-04-16 13:58:48 发布

ZJE_ANDY

最新推荐文章于 2024-04-16 13:58:48 发布

阅读量402

点赞数

分类专栏： Mysql

本文链接：https://blog.csdn.net/u014453898/article/details/109558797

版权

Mysql 专栏收录该内容

25 篇文章 3 订阅

订阅专栏

一、什么是MVCC

MVCC (Multiversion Concurrency Control),即多版本并发控制技术,MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问。你可能会问，实现并发访问的话，加锁不就行了？但是问题就是，加锁解锁耗费资源很多，所以可以使用MVCC来作为替代方案。MVCC可以不加锁来解决多并发的问题。
用简单的话说：MVCC的意思就是对数据库的任何修改的提交都不会直接覆盖之前的数据，而是产生一个新版本与老版本并存，使得读取时可以完全不加锁。这样读取一个数据时，事务可以根据隔离级别选择需要读取哪个版本的数据，整个过程可以完全不用加锁。

MVCC是MySQL的InnoDB引擎实现隔离级别的一种具体方式。用于实现提交读和可重复读

这样，实现两个隔离级别就非常容易：

Read Committed - 一个事务读取数据时总是读这个数据最近一次被commit的版本
Repeatable Read - 一个事务读取数据时总是读取当前事务开始之前最后一次被commit的版本（所以底层实现时需要比较当前事务和数据被commit的版本号）。

二、当前读和快照读

当前读和快照读的概念对MVCC很重要，所以先说一下这两个：

当前读：当前读就是，读取的是数据记录的最新版本，读取时还需要保证其他并发事务不会修改当前记录，因此会对读取的记录上锁。像 select ... lock in share mode、for update、insert、delete这些操作都是当前读。

快照读：像不加锁的select 就是快照读，快照读读到的并不一定是数据的最新版本，有可能是之前的历史版本。所以快照读的实现是基于MVCC(多版本并发控制)的。而且快照读要求隔离级别不能是串行级别的，串行级别下，快照读会退化成当前读。

当前读主要是跟悲观锁有关，快照读则是跟MVCC关联。

三、MVCC原理

1.隐式字段

每行记录除了我们自定义的字段外，还有数据库隐式定义的 TRX_ID 和 ROLL_POINTER。

TRX_ID：这个id用来存储的每次对某条聚簇索引记录进行修改的时候的事务id。

ROLL_POINTER：每次对哪条聚簇索引记录有修改的时候，都会把老版本写入undo日志中。这个roll_pointer就是存了一个指针，它指向这条聚簇索引记录的上一个版本的位置，通过它来获得上一个版本的记录信息。

2.版本链

通过 ROLL_POINTER 就形成了由各个版本构成的版本链，如一开始有数据：

然后现在有个事务id是60的执行的这条记录的修改语句：（就算事务尚未commit，修改的记录也是会写到版本链中的）

此时在undo日志中就存在版本链：

3. ReadView

版本链我们已经看过了，还有一个关键的东西叫readview，这是实行已提交读和可重复读两个隔离级别的关键。

1.readview是什么

MVCC维护了一个ReadVIew结构，主要包含了当前系统未提交的 TRX_IDs {TRX_ID_1, TRX_ID_2, ...}，还有该列表的最小值TRX_ID_MIN 和最大值 TRX_ID_MAX。

ReadView中主要就是有个列表来存储我们系统中当前活跃着的读写事务，也就是begin了还未提交的事务。通过这个列表来判断记录里版本链中的的某个版本是否对当前事务可见。

在进行 SELECT操作时，根据数据行的 TRX_ID 和 TRX_ID_MIN 和 TRX_ID_MAX 之间的关系，从而判断数据行能否被当前事务读取。

例子：假设当前有 ReadView 列表[80，100]，表示当前有已经begin了但还没提交的事务id为80和100。

*这时候，如果你要访问的记录版本的事务ID(即TRX_ID)为50，比ReadView列表的TRX_ID_MIN小，则表示，该事务(ID为50) 已经被提交了(即已经commit)了，这时候是可以读取该事务(TRX_ID=50的事务)所更改的数据版本的。（可读）

*但如果你要访问的记录版本的事务ID是110，那比ReadView列表的TRX_ID_MAX大，则说明这个版本是ReadView生成之后才发生的，所以不能访问该记录版本。（何时生成ReadView下面说，是根据隔离级别不同而不同的）（不可读）

*但如果要访问的记录版本的事务ID是90，在TRX_ID_MIN 和 TRX_ID_MAX之间，那就看看这个TRX_ID在没在ReadView里，如果在，那就说明修改该记录的事务还没提交，那也是不能访问该记录的版本的。因为人家一个事务都还没执行完，你就去读了，你此时读到的数据有可能只是一个中间过程，后面可能还会变，所以如果中途去读的话，那就相当于破坏了事务的原子性了。如果不在ReadView列表里，说明这个事务也已结束了，这时候是可以读的。例如在上述[80，100]列表中，某记录版本的事务ID是90的话，90不在列表中，所以该记录版本是可以读的。

上面所说的记录都是在版本链中找的，先找最近的数据，如果该数据不符合，即不可见(由于事务ID不符合可见要求)，则去找上一个版本的记录，再比较该版本的事务ID与当前ReadView的事务ID，看是否可以访问，以此类推，直到找到可以访问的数据版本或者结束。

2. ReadView什么时候生成

关于ReadView什么时候产生，要看具体的隔离级别，即到底是 读已提交 还是 可重复读 。

在可重复读级别下：

当某个事务对某条记录进行快照读(即不加锁的select)时，会创建一个ReadView，将当前系统活跃的其他事务(即已经begin当还没提交)并记录起来。之后再进行快照读时，还是继续使用同一个ReadView。所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个ReadView，这个ReadView是不变的，所以对之后的修改不可见；所以就达到了无论后面其他事务怎么修改，我当前事务多次select得到的结果都是一样的，这就实现了可重复读。

在读已提交级别下：

某个事务对某个数据每进行一次快照读，都会新生成一个新的ReadView，记录当前时刻系统活跃的其他事务(即已经begin当还没提交)并记录起来，这个事务多次select就会生成多次ReadView，所以并不能保证多次生成的ReadView都一样，因此不能保证同一事务多次select得到的结果一样，因次就产生了不可重复读这个问题。