大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

之前写过事务隔离级别——脏读、不可重复读、幻读。但那是表象。

隔离级别是怎么实现的？为什么InnoDB能做到“读不阻塞写、写不阻塞读”？为什么RR级别下幻读没有被完全解决？

答案都在MVCC（多版本并发控制）里。

今天把MVCC的底层机制彻底拆开讲清楚。

MVCC（Multi-Version Concurrency Control），多版本并发控制。它的核心思想是：

同一行数据在数据库中保留多个版本，不同事务读取时看到的是符合自己隔离级别的那个版本。

InnoDB为每一行数据维护了三个隐藏字段：

——通过它，当前行可以一路回溯到所有历史版本。

每次对数据进行修改（UPDATE或DELETE），InnoDB都会在Undo Log中记录修改前的旧值。修改后，当前行的DB_ROLL_PTR指向Undo Log中的旧版本。

举个例子：一个事务把id=1的name从"张三"改成"李四"，再把age从25改成26。版本链会变成：

当前行: name=李四, age=26, trx_id=100, roll_ptr -> Undo Log
   ↑
Undo Log: name=李四, age=25, trx_id=100, roll_ptr -> Undo Log
   ↑
Undo Log: name=张三, age=25, trx_id=90, roll_ptr -> NULL

版本链的每一个版本都记录了修改它的事务ID。

 这个ID是Read View判断“哪个版本可见”的核心依据。

三、Read View：决定哪个版本可见

Read View是事务在快照读时生成的一个“可见性判断规则”。它包含四个核心字段：

当一个事务要读取某行数据时，沿着版本链从头开始找：

沿着版本链一直找到第一个可见的版本，就是当前事务能读到的数据。

RC下，事务A第一次SELECT时看到的是当时的数据快照。事务B提交后，事务A再次SELECT，会生成新的Read View，看到事务B提交的数据。这就是“读已提交”。

RR下，事务A第一次SELECT生成Read View后，后续所有SELECT都复用这个Read View。即使事务B提交了，事务A也看不到——因为它仍然用旧Read View判断可见性。这就是“可重复读”。

这也解释了为什么RR级别下幻读没有被完全解决。

 快照读（普通SELECT）下，RR确实避免了幻读——因为Read View不变，新插入的行对当前事务不可见。但

）会读取最新数据，如果另一个事务插入了新行，当前读会看到它——这就是幻读。

语句。读取的是Read View决定的历史版本，不加锁，不阻塞写。

。读取的是最新版本，需要加锁。

——读操作不需要加锁，写操作不会被读阻塞。这是InnoDB高并发性能的基石。

历史版本必须保留到不再被任何Read View需要为止。

如果一个事务长时间不提交，它持有的Read View会一直阻止InnoDB清理旧版本。Undo Log不断膨胀，占用大量表空间。

SELECT trx_id, trx_state, trx_started, 
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS duration_sec
FROM information_schema.innodb_trx
WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 60;

如果发现长事务，需要评估是否可以提交或回滚。监控指标

持续增长，说明Undo Log清理不及时，版本链过长。

MVCC是InnoDB并发控制的内核。版本链记录历史，Read View决定可见性，快照读利用MVCC实现无锁读，当前读读取最新版本并加锁。RC和RR的核心差异在于Read View的生成时机——每次SELECT vs 首次SELECT。理解MVCC，才能理解InnoDB为什么能做到高并发下的读写不互相阻塞。

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~

InnoDB MVCC机制全解析：版本链构建、Read View判断逻辑与RC/RR差异

InnoDB的并发控制核心就是MVCC——通过Undo Log版本链和Read View实现“读不阻塞写、写不阻塞读”。本文拆解版本链的构建方式、Read View的四个核心字段、RC与RR隔离级别下Read View生成时机的差异、快照读与当前读的底层区别，以及长事务导致undo log膨胀的根因。

数据库

架构设计

后端

MVCC通过版本链与ReadView实现多版本并发控制，InnoDB利用隐藏字段和UndoLog构建历史版本，快照读不加锁实现读写不阻塞。RC每次SELECT生成新ReadView，RR复用首次快照，导致幻读残留于当前读。理解MVCC机制可优化长事务与UndoLog膨胀问题，提升数据库并发性能。

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

InnoDB MVCC机制全解析：版本链构建、Read View判断逻辑与RC/RR差异

InnoDB MVCC机制全解析：版本链构建、Read View判断逻辑与RC/RR差异

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐