数据库MVCC详解

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 判断数据版本是否可见的逻辑如下：

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

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

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

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

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 恢复该插入操作。

以更新操作为例子：

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

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

• redo log 是 InnoDB 引擎层的物理日志，保证崩溃恢复和持久性。
• binlog 是 MySQL Server 层的逻辑日志，支持主从复制和跨引擎数据恢复。
• 二者结合通过“两阶段提交”确保数据一致性。

2. undo log 会被删除吗？

• 当事务提交且没有其他事务需要访问旧版本数据时，undo log 可以被清理。
• 长事务可能导致 undo log 堆积（“版本膨胀”），影响性能。

3. binlog 和 redo log 的写入顺序？

• 事务提交时，先写 redo log（prepare） → 再写 binlog → 最后写 redo log（commit）。

• 这是为了确保崩溃恢复时，binlog 和 redo log 的一致性（两阶段提交）。

• undo log：保障事务的原子性和 MVCC。

• redo log：保障事务的持久性和崩溃恢复。

• binlog：保障数据可复制性和逻辑恢复。

end.参考

参考：https://www.cnblogs.com/jelly12345/p/14889331.html