什么是数据库MVCC

什么是MVCC

全称是Multi-Version Concurrency Control，即多版本并发控制，主要是为了提高并发性数据库的性能代码>。下面的文章都是关于InnoDB引擎的，因为myIsam不支持事务。

当同一行数据发生读或写请求时，将被锁定并阻塞。但mvcc采用了更好的方式来处理读写请求，这样在发生读写请求冲突时不需要加锁。

此读取指的是快照读取，而不是当前读取。当前的读是一个加锁操作，也就是悲观锁。

那么它是如何实现无锁读写，以及快照读取和当前读取管他呢，跟着你的爱心兄弟继续阅读吧。

什么是当前读和快照读？

MySQL InnoDB 下什么是当前读和快照读？

当前读取

它读取的数据库记录是当前最新版本，当前读取的数据是锁定以防止其他事务修改数据。这是悲观锁的操作。

以下操作均为当前读：

共享模式下选择锁（共享锁）

选择更新（独占锁）

插入（排他锁）

删除（排他锁）

序列化事务隔离级别

快照读取

快照读取的实现是基于多版本并发控制，即MVCC。由于是多版本，快照读取到的数据不一定是最新的数据。它可能是来自以前的历史版本的数据。

以下操作属于快照读取：

快照读取与mvcc的关系

< code>MVCCC 是一个抽象概念，它“维护一个数据的多个版本，以便读写操作不发生冲突”。

这个概念需要具体的功能来实现，这个具体的实现就是快照读取。 （具体实现下文详述）

听了体贴小哥的解释后，厕所是不是瞬间突然打开了？

数据库并发场景

读-读：没有问题，不需要并发控制

读- Write：存在线程安全问题，可能会导致事务隔离问题，以及脏读、幻读、并且可能会遇到不可重复读

Write-Write：是线程安全问题，可能会出现更新丢失问题，比如第一类更新丢失，第二类更新丢失

MVCC 解决了哪些并发问题？

mvcc解决读写冲突的无锁并发控制是给事务分配一个单向增长的时间戳。每次数据修改都会保存一个版本，该版本与交易时间戳关联。

读取操作仅读取事务开始之前的数据库快照。

问题解决如下：

并发读写时间：可以在不阻塞的情况下实现读操作写操作和写入同时进行。该操作也不会阻止读取操作。

解决事务隔离问题如脏读、幻读、不可重复读，但无法解决上述写-写更新丢失 > 问题。

于是就有了下面的组合拳来提高并发性能：

MVCC + 悲观锁 > ：MVCC解决读写冲突，悲观锁解决写写冲突

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

MVCC的实现原理

其实现原理主要是通过版本链、undo log、来实现读取视图

版本链

我们数据库中的每一行数据，除了我们肉眼可以看到的数据外，还隐藏着几个田野，只有打开天眼才能看到。它们是db_trx_id、db_roll_pointer、db_row_id。

db_trx_id

6byte，最近修改（修改/插入）事务ID：记录创建此记录/此记录的最后修改的事务 ID。

db_roll_pointer（版本链密钥）

7byte，回滚指针，指向本条记录的上一条 Version（存储在回滚段中）

db_row_id

6byte，隐式自增ID（隐藏主键），如果数据表没有主键，InnoDB会根据db_row_id自动生成聚集索引。

实际上有一个删除标志隐藏字段。记录更新或删除这一事实并不意味着它实际上已被删除。这是删除标志发生了变化

如上所示，db_row_id是唯一隐含的数据库默认为该行记录生成的主键。 ，db_trx_id是当前对记录操作的事务ID，db_roll_pointer是用于协调的回滚指针 撤消日志，指向之前的旧版本。

每次修改数据库记录时，都会记录一个撤消日志。每个undo log还有一个roll_pointer属性（对应INSERT操作，undo log没有这个属性，因为记录没有更早的版本），这些undo log可以是connect，字符串变成链表，所以现在的情况如下图：

每次更新记录后，旧值都会被放到一个撤消日志。即使是旧版本的记录，随着更新次数的增加，增加，所有版本都会连接成一个链表 通过 roll_pointer 属性。我们把这个链表称为版本链，即版本链的头节点。它是当前记录的最新值。另外，每个版本还包含该版本生成时对应的交易id。这个信息非常重要，在根据ReadView判断版本的可见性时会用到。

撤消日志

撤消日志主要用于记录数据修改之前的日志。表信息修改前，会将数据复制到undo log中。

当事务回滚时，您可以通过undo log中的日志数据恢复。

撤消日志的目的

执行回滚时确保事务的原子性并且一致性，当事务回滚时，undo log数据可以用于恢复。

MVCC快照读取使用的数据，在MVCC多版本控制中，通过读取undo log<的历史版本数据 /code> code>可以实现不同的交易版本号有各自的独立的快照数据版本。

undo log主要分为两种：

insert undo log

表示事务插入一条记录时产生的undo log新记录，只有事务回滚时才需要，事务提交后可以立即丢弃

更新undo log（主）

事务提交时产生的undo log更新或删除；不仅事务回滚时需要，快照读取时也需要；

所以不能随便删除。只有当日志不涉及快读或者事务回滚时，对应的日志才会被purge线程统一。清除

Read View（读取视图）

事务执行快照读取操作时产生的读取视图（Read View），快照读取在事务执行期间，将会生成数据库系统当前状态的快照。

记录并维护系统当前活动事务的ID（没有commit，每个事务启动时都会被分配一个ID。这个ID是不断增加的，所以越新的事务交易，ID值越大），它是系统中此交易不应该看到的其他交易ID的列表。

Read View主要用于可见性判断，即当我们某个事务执行快照读取时，为记录创建一个读取视图，将其与条件进行比较以确定当前事务可以看到哪个版本的数据，它可以可以是当前最新数据，也可以是该行记录的undo log中某个版本的数据。

读取查看多个属性

trx_ids：当前系统活动（未提交）事务的集合版本号。

low_limit_id：创建当前读取视图时“当前系统最大交易版本号+1”。

up_limit_id：创建当前读取视图时，“系统处于活动事务最低版本号”

< code>creator_trx_id：创建当前读取视图的事务版本号；

读取视图可见性判断条件

db_trx_id < up_limit_id || db_trx_id == creator_trx_id（显示）

如果数据事务ID小于最小活动事务ID阅读视图，您可以确保数据在当前事务启动之前存在，因此可以显示。

或者数据的交易ID等于creator_trx_id，则说明该数据是当前交易自行生成的生成。当然数据本身是可以看到的，所以在这种情况下数据也可以被显示。

db_trx_id >= low_limit_id（不显示）

如果数据事务ID大于当前系统的最大事务ID表示数据是在当前读取视图创建之后生成的，因此数据不显示。如果小于，则进入下一步判断

db_trx_id是否在活跃事务（trx_ids）

不存在：表示事务已提交n 生成读取视图。在这种情况下，可以显示数据。

已经存在：这意味着当我的Read View生成时，你的事务仍然处于活动状态并且尚未提交。你修改的数据对于我当前的交易也是不可见的。

MVCC和事务隔离级别

上面提到的Read View是用来支持RC（Read Comfilled，读提交）以及RR（可重复读取）隔离级别的实现。

RR和RC生成时序

RC隔离级别，每次快照读取都会生成并获取最新的Read View;

并且在RR隔离级别下，是在同一个事务中 第一个快照读取将创建一个Read View，后续快照读取将获得相同的Read View，后续查询将不会重复生成，因此一笔交易的查询结果每次都会相同。

解决幻读问题

快照读：通过MVCC控制，无需加锁。按照MVCC规定的“语法”进行增删改查等操作，避免幻读。

当前读：通过next-key锁（行锁+间隙锁）解决问题。

InnoDB RC 和 RR 级别快照读取的区别

RR 级别事务对记录的第一次快照读取将创建快照和 Read View，记录其他活动事务在现行制度下。此后调用快照读取时，仍将使用相同的读取视图。因此，只要当前事务在其他事务提交更新之前已经使用了快照读，那么后续的快照读就会使用它们都是同一个Read View，所以后续的修改是不可见的；

也就是说，在RR级别，当一个snapshot读生成一个Read View时，该Read View会记录所有其他的snapshot此时交易活跃。修改对当前事务不可见。早于Read View创建的事务所做的修改都是可见的

在RC层面，事务中，每次快照读取都会生成新的快照和Read View。这就是我们在RC级别下的交易中，可以看到其他交易提交更新的原因

总结

从上面的描述中，我们可以看到所谓MVCC是指在执行普通操作时，使用READ COMMITTD和REPEATABLE READ两个隔离级别的事务访问记录的版本链 SEELCT 操作。 > 以这种方式处理读写和不同事务的写-读操作可以并发执行，从而提高系统性能。

读完这篇文章，相信你对什么是数据库MVCC有了一定的了解。如果您想了解更多相关知识，请关注行业资讯频道。感谢您的阅读！