RC确实是每次查询都生成读视图,但是都是快照读啊,和读已提交没半毛钱关系吧

文章目录1. 语义纠偏快照并不等于“旧照片”2. 举个例子刷新朋友圈3. 为什么它和“读已提交”没脱节4. 总结 追问一个硬核点哈哈我特别喜欢你这种钻研精神你这个质疑点其实踩到了很多开发者对“快照Snapshot”这个词的语义误区。你觉得没关系是因为你潜意识里觉得“快照”就应该是恒定不变的。但实际上在数据库的世界里“快照”不是终身制的它的有效期是可以配置的。我们来拆解一下为什么说 RC 的快照读恰恰就是为了实现“读已提交”1. 语义纠偏快照并不等于“旧照片”在 MVCC 语境下“快照读”的本质是不加锁根据 Read View 规则去版本链里找数据。RC读已提交的逻辑每执行一次SELECT就当场重新拍一张系统当前的快照Read View。“已提交”体现在哪这张当场拍的快照会把那一刻所有已经提交的事务 ID标记为“可见”。所以虽然它叫“快照读”但因为它刷新的频率太快了每条查询刷一次导致它每次都能捕捉到别人刚刚提交的最新变动。2. 举个例子刷新朋友圈我们可以把 RC 和 RR 的快照读对比一下你就秒懂了RC读已提交就像你在刷朋友圈。你每点一次“刷新”系统就给你一张此时此刻的“快照”。如果刚才你朋友发了条动态事务提交了你这次刷新就能看到。你看到的是“那一刻已提交”的状态。RR可重复读就像你进朋友圈时点了一下“截图”。不管你之后怎么刷新你都只盯着手里这张截图看。就算你朋友发了 100 条新动态事务提交了你手里那张图也不会变。3. 为什么它和“读已提交”没脱节“读已提交”这个隔离级别的核心定义是只要事务没提交我就看不见只要提交了我就能看见。在 RC 级别下MVCC 完美地完成了这个任务屏蔽未提交Read View 会把当前还在活跃未提交的事务 ID 记下来版本链里凡是属于这些 ID 的数据统统跳过。拥抱已提交因为每条查询都重开 Read View所以只要一个事务提交了它的 ID 就不再属于“活跃事务”在下一条查询的 Read View 里它就变成了“可见”。结论它是通过不断更新快照的内容来对齐“读已提交”的业务需求。4. 总结你之所以觉得“没半毛钱关系”可能是把快照读方式和可重复读结果搞混了。快照读是技术手段不加锁读版本链。读已提交是隔离目标。在 RC 里我们用“短命”的快照读实现了读已提交。在 RR 里我们用“长命”的快照读实现了可重复读。 追问一个硬核点如果你在 RC 级别下一个事务里执行了两条一模一样的SELECT中间另一个事务提交了修改。按照你的理解如果这两次查询结果不一样发生了不可重复读这算不算“读到了已提交的数据”这正是 RC读已提交隔离级别被允许的行为而 MVCC 只是那个帮它“瞬移”快照的工具人。