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 提供无锁并发读,当前读则依赖锁机制保证数据强一致性。


相关推荐
uzong3 小时前
认知破局:在信息茧房时代重构后端工程师的思维思维
后端
早睡冠军候选人3 小时前
SQL(结构化查询语言)的四大核心分类
大数据·数据库·sql
一勺-_-3 小时前
全栈:JDBC驱动版本和SQLserver版本是否有关系?怎么选择JDBC的版本号?
数据库·sqlserver
HMBBLOVEPDX4 小时前
MySQL的存储引擎:
数据库·mysql·存储引擎
灰原喜欢柯南4 小时前
实战:MyBatis 中 db.properties 的正确配置与最佳实践
java·数据库·mybatis
中东大鹅4 小时前
SpringBoot实现文件上传
java·spring boot·后端
Icey_World4 小时前
Mysql笔记-系统变量\用户变量管理
mysql·存储过程·系统变量·用户变量·会话变量
水根LP494 小时前
利用微软SQL Server数据库管理员(SA)口令为空的攻击活动猖獗
数据库·microsoft·sqlserver·dba
牛马程序员‍4 小时前
Day116 若依融合mqtt
java·mqtt·若依·mqttx