SQL MVCC 的基本工作原理

MVCC是通过版本快照实现的并发控制机制，而非锁；它让每个SELECT看到事务启动时刻的一致性快照，依赖DB_TRX_ID、DB_ROLL_PTR和ReadView协同判断版本可见性。

什么是 MVCC：它不是“锁”，而是“版本快照”

MVCC 的本质，是让每个 SELECT（快照读）看到一个**与自己事务启动时刻一致的数据快照**，而不是实时最新值。它不靠加锁阻塞别人，而是靠保存历史版本+判断可见性来实现隔离。你执行 SELECT 时，InnoDB 不会去查当前行是不是被别人改了，而是顺着 DB_ROLL_PTR 往 Undo Log 里找——哪个版本对“我这个事务 ID”是可见的，就返回哪个。

三个隐藏字段怎么协作：DB_TRX_ID、DB_ROLL_PTR、ReadView 是铁三角

每一行数据背后都藏着 InnoDB 自动维护的“元信息”：

• DB_TRX_ID：记录最后一次修改这行的事务 ID；插入/更新/删除都会更新它（删除其实是打标记+写新版本）
• DB_ROLL_PTR：像一根“回溯绳”，指向 Undo Log 里该行的上一个版本；多个版本由此串成一条链（版本链）
• ReadView：事务做快照读时生成的“可见性快照”，里面存着当时活跃事务 ID 列表、最小未提交事务 ID（m_ids）、最大已提交事务 ID（up_limit_id）等关键信息

判断某版本是否可见，就靠 ReadView 里的规则：该版本的 DB_TRX_ID 必须小于 up_limit_id，且不能出现在 m_ids 活跃列表中——否则说明它还没提交，或正在并发修改，对你不可见。

RR 和 RC 隔离级别差异在哪：ReadView 生成时机决定一切

同一个 SQL，在 REPEATABLE READ 和 READ COMMITTED 下行为不同，根源就在 ReadView 创建时间：

• REPEATABLE READ：第一次 SELECT 时创建 ReadView，整个事务复用它 → 后续 SELECT 看到的仍是同一份快照 → 实现“可重复读”
• READ COMMITTED：每次 SELECT 都新建 ReadView → 能看到其他事务刚提交的新版本 → 可能出现

  

  “不可重复读”

注意：SELECT ... FOR UPDATE 或 UPDATE 是“当前读”，不走 MVCC 快照逻辑，直接读最新行并加锁，所以无论什么隔离级别，它们都会看到最新已提交数据（甚至触发锁等待）。

为什么有时候 MVCC “失效”了：常见误判场景

你以为在用 MVCC，其实可能已经掉进陷阱：

• 没主键或唯一索引的表，InnoDB 会用 DB_ROW_ID 做聚簇索引，但这个 ID 不参与可见性判断 —— 容易导致幻读感知变强（尤其配合 INSERT）
• 长事务不提交，它的 ReadView 一直有效，会阻止 Purge 线程清理旧 Undo 版本 → Undo Log 膨胀、磁盘撑爆
• DELETE 后立即 SELECT 看不到数据，不是 MVCC 失效，而是你用了当前读（比如加了 FOR UPDATE），或者事务还没提交，旧版本被标记为“逻辑删除”但仍在链上

真正要验证 MVCC 是否起作用，得用纯 SELECT + 显式开启事务 + 控制提交顺序，再比对两次查询结果 —— 其他操作都可能绕过快照逻辑。