谈谈MVCC机制

本文主要是介绍谈谈MVCC机制，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在MySQL中，MVCC（多版本并发控制）是InnoDB存储引擎使用的并发控制机制。它提供对数据的并发访问，并确保多用户环境中数据的一致性和隔离性。

InnoDB通过“Undo log”存储每条记录的多个版本，提供历史记录供读取，并允许不同的事务访问不同的数据版本。在事务期间，客户端只能看到当前事务开始之前提交的记录以及当前事务内所做的修改。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

隔离级别

MySQL中有4种隔离级别：

READ UNCOMMITED

当前事务可以读取未提交的数据。这些数据可能会回滚，所以我们将未提交的数据称为脏数据，这种问题称为脏读。

READ COMMITED

当前事务确实可以读取已提交的数据，因此不存在脏读问题。但是，如果当前事务多次读取同一条记录，则可能检索到不同的数据。这是因为，在当前事务期间，可能有其他事务修改并提交了该记录。此问题称为不可重复读。

REPETABLE READ

事务多次读取特定的记录集，即使其他事务在事务过程中修改或提交对这些记录的更改，它也始终会获得这些记录的相同值。但是，如果我们在当前事务中多次执行“SELECT COUNT(*) FROM {table_name}”，我们可能会看到不同的结果，这个问题称为幻读。

REPEATABLE READ 是 MySQL InnoDB 中的默认隔离级别。

SERIALIZABLE

所有事务都强制排序，解决了脏读、不可重复读、幻读等问题。但Serialized隔离级别性能较差，因此在实际中很少使用。

MVCC 仅适用于 READ COMMITTED 和 REPEATABLE READ 隔离级别，因为 READ UNCOMMITTED 始终读取最新记录，而 SERIALIZABLE 会为其读取的所有记录添加锁。

概念

TRANSACTION ID

当一个新的事务开始时，它会得到一个自增的事务ID，通过它InnoDB可以知道每个事务的执行顺序。

隐藏列

InnoDB中的每条记录都有两个隐藏列“db_trx_id”和“db_roll_pointer”，如果表中没有主键或非空唯一键，InnoDB将生成一个隐藏的自增列“db_row_id”。

字段名称	描述
db_trx_id	记录操作该行的事务的事务id
db_roll_pointer	undo指针，指向该行的undo日志

InnoDB 在撤消日志中记录“插入”、“更新”和“删除”操作。然而，对于“删除”操作，InnoDB实际上将其记录为“更新”操作，即通常所说的“软删除”。InnoDB 不是物理删除该行，而是更新“已删除标志”来指示该行已被逻辑删除。此方法允许检索该行的先前版本，如果该行被永久删除，则无法检索先前版本。

当前读

一些 SQL 语句，例如“SELECT * ... LOCK IN SHARE MODE(共享锁)”、“SELECT * ... FOR UPDATE(独占锁)”、“UPDATE”、“DELETE”和“INSERT”， 考虑当前的读取操作。这些操作读取该行的最新版本。在读取过程中，InnoDB通过对当前记录加锁来确保没有其他事务可以修改当前记录。

快照读

没有加锁的 SELECT 语句被视为快照读取操作，通过 MVCC 读取所需的版本。快照读取无锁，有效提升事务性能。

本质上，快照是一种以空间换取时间的方式。

Undo log

Undo log存储修改行的先前版本。在行被修改之前，InnoDB会将当前版本复制到Undo log中，Undo log具有以下功能：

• 如果事务回滚，InnoDB可以找到以前的版本来恢复。

• 如果当前版本对于当前事务不可见，则会通过undo log查找可见版本。

前面提到，InnoDB将删除操作记录为更新操作，因此Undo Log中只有两种操作：

• Insert undo log：由insert操作产生，仅用于事务回滚，事务提交后可立即丢弃。

• 更新undo log：由更新操作生成，不仅用于事务回滚，还用于快照读取。

版本链

当多个事务同时操作同一条记录时，每个事务都会生成一个新的版本，这些版本通过 db_roll_pointer 形成一个链表，称为版本链。

 

Read View

ReadView是事务执行快照读取时生成的记录快照。

读取视图存储当前事务开始之前的所有活动事务。有 4 个重要属性：

• trx_ids：活动事务ID（不包括当前事务和已提交事务）。

• low_limit_id：分配的下一个交易ID。

• up_limit_id：trx_ids中的最小交易id，如果trx_ids为空，则up_limit_id等于low_limit_id。

• Creator_trx_id：生成读取视图的事务ID。

以下规则用于检查记录是否对当前事务可见：

• 如果访问版本的事务ID=creator_trx_id，则表示当前事务访问了自己修改过的记录，则该版本对当前事务可见。

• 如果访问版本的事务ID < up_limit_id，则说明生成该版本的事务在当前事务生成ReadView之前已经提交，因此该版本可以被当前事务访问。

• 如果访问版本的事务ID > low_limit_id 值，则说明生成该版本的事务是在当前事务生成ReadView之后打开的，因此当前事务无法访问该版本。

• 如果访问版本的事务ID在up_limit_id和m_low_limit_id之间，则需要判断该版本的事务ID是否在trx_ids列表中。如果是，说明该版本生成的事务在ReadView创建时仍然处于活动状态，该版本无法访问。

• 如果没有，说明创建ReadView时生成该版本的事务已经提交，可以访问该版本。

MVCC实现原理

了解了上面的概念后，MVCC的实现就很好理解了。

查询流程

1. 获取交易自己的交易ID，称为trx_id。（这不是在 SELECT 语句期间获得的，而是在事务开始时获得的，即执行 BEGIN 时获得的。）

2. 检索 ReadView（仅在 SELECT 语句期间生成）。

3. 在数据库表中，如果找到数据，则将其与ReadView中的事务版本号进行比较。4、如果不符合ReadView的可见性规则，则需要Undo Log中的历史快照，直到返回符合规则的数据。

InnoDB通过ReadView和Undo Log的结合来实现MVCC。Undo Log 存储历史快照，而 ReadView 的可见性规则有助于确定当前版本数据的可见性。

这篇关于谈谈MVCC机制的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---