IT评测·应用市场-qidao123.com

标题: 数据库MVCC详解 [打印本页]

---

作者: 伤心客    时间: 2025-3-20 20:00
标题: 数据库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 的生成规则不同（例如“读已提交”每次读都生成新快照，“可重复读”使用事务启动时的快照）。
  

②示例

有这样一张表，内里有记录。
idnameageDB_TRX_IDDB_ROLL_PTR1Alice251000x0000初始版本由事务 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）仍旧存在。

1. id | name  | age | DB_TRX_ID | DB_ROLL_PTR     【这个是新版本V2】
2. ---|-------|-----|-----------|------------
3. 1  | Alice | 26  | 200       | 0x1234（指向旧版本V1）
4.                                  丨丨
5.                                  丨丨
6.                                   ↓
8. id | name  | age | DB_TRX_ID | DB_ROLL_PTR     【这个是旧版本V1】
9. ---|-------|-----|-----------|------------
10. 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读到的如下：

1. id | name  | age
2. ---|-------|-----
3. 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 参数控制刷盘频率。
  

我来举个例子：

1. -- 事务C: 删除一行数据
2. BEGIN;
3. DELETE FROM users WHERE id = 1;
4. COMMIT;
6. -- 提交后，binlog 记录该 DELETE 语句（或行变化）。从库读取 binlog 并重放，保持数据一致性。

复制代码

③ Redo Log（重做日志）

作用

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

工作机制

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

我来举个例子：

1. -- 事务B: 插入一条新数据
2. BEGIN;
3. INSERT INTO users (id, name) VALUES (2, 'Bob');
4. COMMIT;
6. -- 提交时，redo log 记录插入操作的物理页修改，之后数据可能还未写入磁盘。
7. -- 若此时崩溃，重启后根据 redo log 恢复该插入操作。

复制代码

以更新操作为例子：

• 事务执行：修改数据前，将旧值记录在undo log；最终还是要修改磁盘数据的，还记录一下修改的物理页位置 redo log
  
• 事务提交：redo log标记为prepare 状态并刷盘。 写入 binlog 并刷盘。将 redo log 标记为 commit 状态（两阶段提交，包管同等性）。
  
• 崩溃恢复： 若崩溃发生在 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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)

Powered by Discuz! X3.4