MVCC的底层实现原理是什么?

MVCC(多版本并发控制)的底层实现核心在于数据版本链可见性判断规则(Read View) ,InnoDB 通过 Undo LogRead View 协同工作实现这一机制。以下是详细原理:


一、核心组件与流程

1. 数据版本链 (Undo Log)
  • 作用:存储数据行的历史版本,构成版本链。
  • 结构
    • 每行数据包含两个隐藏字段:
      • DB_TRX_ID (6字节):最近修改该行的事务ID。
      • DB_ROLL_PTR (7字节):指向该行上一个历史版本在 Undo Log 中的指针。
    • 每次更新数据时:
      1. 生成新的 Undo Log 记录旧数据。
      2. 新行写入当前数据,DB_TRX_ID 设为当前事务ID。
      3. DB_ROLL_PTR 指向刚生成的 Undo Log 记录。
  • 版本链形成 :通过 DB_ROLL_PTR 指针,将同一数据行的所有历史版本串联成一个链表(按修改时间倒序),链头是最新版本。
2. 快照视图 (Read View)
  • 作用 :事务执行快照读 (如 SELECT)时创建,用于判断版本链中哪个版本对该事务可见。
  • 关键属性
    • m_ids:生成 Read View 时,系统中所有活跃(未提交)事务ID的集合。
    • min_trx_idm_ids 中的最小事务ID。
    • max_trx_id:生成 Read View 时,系统应分配给下一个新事务的ID(即当前最大事务ID+1)。
    • creator_trx_id:创建该 Read View 的事务ID(对于只读事务,可能为0)。
  • 可见性判断规则 :遍历版本链时,对每个版本的 DB_TRX_ID (记为 trx_idtrx\_idtrx_id) 应用以下规则:
    1. 可访问 :如果 trx_id<min_trx_idtrx\_id < min\_trx\_idtrx_id<min_trx_id,说明该版本在 Read View 创建前已提交,可见
    2. 不可访问 :如果 trx_id≥max_trx_idtrx\_id \geq max\_trx\_idtrx_id≥max_trx_id,说明该版本在 Read View 创建后才生成,不可见
    3. 活跃事务 :如果 min_trx_id≤trx_id<max_trx_idmin\_trx\_id \leq trx\_id < max\_trx\_idmin_trx_id≤trx_id<max_trx_id:
      • 若 trx_id∈m_idstrx\_id \in m\_idstrx_id∈m_ids,说明该版本由未提交的事务修改,不可见
      • 若 trx_id∉m_idstrx\_id \notin m\_idstrx_id∈/m_ids,说明该版本在 Read View 创建时已提交,可见
    4. 自身修改 :如果 trx_id=creator_trx_idtrx\_id = creator\_trx\_idtrx_id=creator_trx_id,说明该版本是当前事务自己修改的,可见
  • 遍历过程 :从最新版本开始,依次检查 DB_TRX_ID,直到找到第一个满足可见性条件的版本。

二、不同隔离级别的实现差异

1. 读已提交 (READ COMMITTED)
  • Read View 生成时机每次执行快照读时 都会生成一个新的 Read View
  • 效果 :每次读都能看到最新已提交的数据。其他事务只要提交,当前事务的下一次读就能看到。
2. 可重复读 (REPEATABLE READ - InnoDB默认)
  • Read View 生成时机 :在事务中第一次执行快照读时 生成,后续所有快照读都复用同一个 Read View
  • 效果 :在整个事务期间,看到的数据版本是一致的(第一次读时的快照),不受其他已提交事务影响,实现了可重复读 。同时,通过 Next-Key Lock 防止幻读。

三、关键概念区分

  1. 快照读 (Snapshot Read)
    • 普通 SELECT 语句(不加 FOR UPDATE/SHARE)。
    • 基于 MVCC 机制读取历史版本。
    • 无锁(或仅加极轻量级的锁,如检查 schema 版本)。
  2. 当前读 (Current Read)
    • SELECT ... FOR UPDATE/SHARE, UPDATE, DELETE, INSERT
    • 总是读取最新已提交的数据版本。
    • 需要加锁(记录锁、间隙锁、Next-Key Lock)以保证数据一致性和防止冲突。

四、垃圾回收 (Purge)

  • 问题 :历史版本 (Undo Log) 不会永久保留。
  • 机制 :InnoDB 后台的 Purge 线程负责清理不再需要的旧版本数据。
  • 清理条件 :当系统中没有 任何 Read View 需要访问某个旧版本时,该版本才能被安全删除。

总结 :MVCC 的底层实现 = Undo Log 构建版本链 + Read View 判断可见性 。通过控制 Read View 的生成时机,实现了不同隔离级别的语义。快照读依赖 MVCC 提供无锁并发读,当前读则依赖锁机制保证数据强一致性。


相关推荐
小楓120113 分钟前
MySQL數據庫開發教學(四) 後端與數據庫的交互
前端·数据库·后端·mysql
这里有鱼汤13 分钟前
A股预测还能更准?开源大模型Kronos带你跑通预测+回测全流程
后端·python
shark_chili22 分钟前
Java程序员的Linux性能调优宝典:三大经典场景深度剖析
后端
血手人屠喵帕斯25 分钟前
Redis核心原理与Java应用实践
java·数据库·redis
设计师小聂!26 分钟前
redis详解 (最开始写博客是写redis 纪念日在写一篇redis)
java·数据库·redis·缓存·bootstrap
她说..26 分钟前
Redis的Java客户端
java·数据库·redis·nosql数据库·nosql
小流苏生28 分钟前
或许,找对象真的太难了……
前端·后端·程序员
YSRM28 分钟前
Leetcode+Java+动态规划IV
java·leetcode·动态规划
麦兜*31 分钟前
大模型时代:用Redis构建百亿级向量数据库方
数据库·spring boot·redis·spring·spring cloud·缓存
DemonAvenger38 分钟前
分区表实战:提升大表查询性能的有效方法
数据库·mysql·性能优化