当前位置：首页 > article >正文

数据库MVCC详解

article 2025/3/26 4:12:22

MVCC

1.基本介绍

数据库：MySQL。【很多主流数据库都使用了MVCC，比如MySQL的InnoDB引擎、PostgreSQL、Oracle】

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。是数据库管理系统中的一种并发控制方法。

MVCC的基本原理: 它通过保存数据的历史版本来实现，这样读操作不会被写操作阻塞，写操作也不会被读操作阻塞。这样的话，提高了并发性能。比如说，当一个事务开始读取数据时，它会看到数据库在某个时间点的快照，之后即使其他事务修改了数据，这个事务看到的还是旧版本的数据，直到它提交或者回滚。

不同的隔离级别（如读已提交、可重复读、串行化）在MVCC中的实现方式不同。例如，在读已提交级别下，每次读取都会获取最新的快照，而可重复读则是在事务开始时确定快照，后续读取都基于这个快照，从而避免不可重复读的问题。

当前读和快照读

当前读：像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。
快照读：像不加锁的select操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC,可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

MVCC就是为了实现读-写冲突不加锁，而这个读指的就是快照读, 而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现

当前读 <==> 悲观锁; 快照读 <=> 乐观锁？

2.mvcc实现原理

数据库不知道的秘密。

每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段

DB_TRX_ID：6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID ---------【事务ID】
DB_ROLL_PTR：7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里） -----------------【回滚指针】
DB_ROW_ID：6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引 ----------【隐藏主键】
实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了 --------【删除标记】

① MVCC 核心机制

版本链：每行数据通过隐藏字段 DB_TRX_ID（事务ID）和 DB_ROLL_PTR（回滚指针）维护多个版本。
ReadView：事务启动时生成一个“快照”，记录当前活跃事务的 ID 列表，用于判断数据版本的可见性。
事务隔离级别：不同隔离级别下，ReadView 的生成规则不同（例如“读已提交”每次读都生成新快照，“可重复读”使用事务启动时的快照）。

②示例

有这样一张表，里面有记录。

id	name	age	DB_TRX_ID	DB_ROLL_PTR
1	Alice	25	100	0x0000

初始版本由事务 txid=100 提交生成；DB_ROLL_PTR 指向旧版本（初始为 NULL）。

这个时候有两个事务来了。

事务A（txid=200）：执行 UPDATE user SET age=26 WHERE id=1。
事务B（txid=201）：在事务A提交前，执行 SELECT * FROM user WHERE id=1。

事务A 更新数据，InnoDB引擎，会为这行数据创建一个新版本，并修改 DB_TRX_ID=200，DB_ROLL_PTR 指向旧版本（事务100提交的版本）。

这个时候，还没有A事务还没有提交，新版本（V2）还未提交，旧版本（V1）仍然存在。

id | name  | age | DB_TRX_ID | DB_ROLL_PTR     【这个是新版本V2】
---|-------|-----|-----------|------------
1  | Alice | 26  | 200       | 0x1234（指向旧版本V1）
                                 丨丨
                                 丨丨
                                  ↓

id | name  | age | DB_TRX_ID | DB_ROLL_PTR     【这个是旧版本V1】
---|-------|-----|-----------|------------
1  | Alice | 25  | 100       | 0x0000

然后，事务B读取数据，事务B 启动时会生成一个 ReadView，记录当前活跃事务的 ID 列表。假设此时只有事务A（txid=200）未提交，活跃事务列表为 [200]

事务B 根据 ReadView 判断数据版本的可见性：

规则：若数据版本的 DB_TRX_ID 小于当前事务的 txid，且该事务已提交，则可见。
当前数据最新版本是 V2（DB_TRX_ID=200），但事务B 的 ReadView 显示 txid=200 是活跃的（未提交），因此 V2 不可见。
事务B 沿着回滚指针（DB_ROLL_PTR）找到旧版本 V1（DB_TRX_ID=100），判断 100 < 201 且已提交，因此返回 V1 的数据：

故，事务B读到的如下：

id | name  | age 
---|-------|-----
1  | Alice | 26

可以看到上述读写，好像没有加锁。。

③可见性规则

InnoDB 判断数据版本是否可见的逻辑如下：

如果数据版本的 DB_TRX_ID 小于当前事务的 txid，且该事务已提交 → 可见，【怎么看提交了没有呢？看事务的活跃列表】。
如果数据版本的 DB_TRX_ID 等于当前事务的 txid → 可见（事务可以看到自己的修改）。
如果数据版本的 DB_TRX_ID 大于当前事务的 txid → 不可见（属于未来的修改）。
如果数据版本的 DB_TRX_ID 在事务的 ReadView 活跃列表中 → 不可见（该事务尚未提交）。

MVCC 通过维护数据多版本和 ReadView 机制，实现读写不阻塞和高并发：

写操作：生成新版本，不影响其他事务的读操作。
读操作：基于快照读取旧版本，无需加锁。
提交后的版本：对新事务可见，旧事务仍看到历史版本。

这种机制在保证事务隔离性的同时，极大提升了数据库并发性能。

3.补充知识点

MySQL 中的 undo log、redo log 和 binlog 是三种核心日志，各自承担不同的职责，共同保障数据库的事务性、持久性和高可用性

下面三个是参考deepseek的解释。

① Undo Log（回滚日志）

作用

事务回滚：记录数据修改前的旧值，用于事务回滚时恢复原始数据。
MVCC（多版本并发控制）：提供历史版本数据，支持一致性非锁定读（Consistent Non-locking Read）。

工作机制

当执行 INSERT、UPDATE 或 DELETE 时，InnoDB 会将修改前的数据保存到 undo log。
事务回滚：通过 undo log 逆向操作，恢复数据到修改前的状态。
MVCC 实现：其他事务读取数据时，若当前版本不可见（如未提交），则通过 undo log 找到可见的历史版本。

见上面的mvcc。

② Binlog（二进制日志）

作用

主从复制：记录所有数据库修改操作，用于主库到从库的数据同步。
数据恢复：支持按时间点恢复数据（Point-in-Time Recovery, PITR）。

工作机制

逻辑日志：记录 SQL 语句或行的逻辑变化（取决于 binlog_format：STATEMENT、ROW、MIXED）。
写入时机：事务提交后写入 binlog（与 redo log 不同）。
刷盘控制：由 sync_binlog 参数控制刷盘频率。

我来举个例子：

-- 事务C: 删除一行数据
BEGIN;
DELETE FROM users WHERE id = 1;
COMMIT;

-- 提交后，binlog 记录该 DELETE 语句（或行变化）。从库读取 binlog 并重放，保持数据一致性。

③ Redo Log（重做日志）

作用

崩溃恢复：确保事务的持久性（Durability）。即使数据库崩溃，已提交的事务修改不会丢失。
Write-Ahead Logging (WAL)：修改数据前，先记录重做日志到磁盘。

工作机制

事务提交时，先将所有修改的物理页变化记录到 redo log（顺序写入，性能高）。
刷盘策略：由 innodb_flush_log_at_trx_commit 控制：
- 1（默认）：每次提交都刷盘，保证崩溃恢复不丢数据。
- 0 或 2：延迟刷盘，性能更高但可能丢失部分数据。
崩溃恢复：重启后，通过 redo log 重放未写入数据文件的修改。

我来举个例子：

-- 事务B: 插入一条新数据
BEGIN;
INSERT INTO users (id, name) VALUES (2, 'Bob');
COMMIT; 

-- 提交时，redo log 记录插入操作的物理页修改，之后数据可能还未写入磁盘。
-- 若此时崩溃，重启后根据 redo log 恢复该插入操作。

以更新操作为例子：

事务执行：修改数据前，将旧值记录在undo log；最终还是要修改磁盘数据的，还记录一下修改的物理页位置 redo log
事务提交：redo log标记为prepare 状态并刷盘。写入 binlog 并刷盘。将 redo log 标记为 commit 状态（两阶段提交，保证一致性）。
崩溃恢复：若崩溃发生在 binlog 写入前，事务回滚（通过 undo log）。若 binlog 已写入，则根据 redo log 重放修改。

1. 为什么需要 redo log 和 binlog 两种日志？