当前位置：首页 > 问答 > 正文

说说PostgreSQL里那个挺复杂的MVCC到底是咋回事儿，怎么保证数据不乱套

称怜
问答
2025-12-29 18:25:34
2

说到PostgreSQL里那个挺复杂的MVCC，咱们可以把它想象成一个特别讲究的图书馆管理图书版本的方法，目的就是为了让好多人同时看书、借书、还书的时候，谁也不耽误谁,书架上的书也不会乱套。

核心思想：不删旧数据，直接添新的

普通的管理方法可能像这样：一本书只有一个副本，你想修改书里的一页，就得把这页撕下来，贴上新的，这期间，别人要么等着你贴完，要么就可能读到半新半旧、内容不一致的书页。

PostgreSQL的MVCC（多版本并发控制）不这么干，它的做法是，当你想修改一条数据（比如把用户张三的年龄从20岁改成21岁）时，它不会直接去把那个“20岁”的记录给覆盖掉，相反，它会重新抄写一份完整的记录，在这份新的抄本上把年龄改成21岁，然后把旧的记录（20岁）和新的记录（21岁）都留在书架上（也就是数据库里）。

那怎么知道哪本是当前最新的书呢？——用“身份证”和“时间戳”

为了区分哪个版本的数据是当前有效的，PostgreSQL给每一条数据（每一行）都偷偷加了两个看不见的“身份证”字段（根据PostgreSQL官方文档，通常是xmin和xmax这类事务ID字段）。

xmin：可以理解为这本“书”（数据行）的“出版日期”或者说“上架日期”，它记录的是创建这个数据版本的那个事务的ID，只有当你的“阅读许可证”（当前事务ID）晚于这个“出版日期”,你才被允许看到这本书。
xmax：这个可以理解为“下架日期”或“预定删除日期”，它最初是空的，当有人要删除这条数据时，就会在这个字段填上自己的事务ID，标记这本书“准备下架”，当有人要更新这条数据时（也就是我们前面说的抄写新版本），它也会在旧版本的数据上把这个字段填上自己的ID，意思是“此旧版已作废，请参考新版”。

任何一个时刻，当你要读数据时，PostgreSQL会根据你当前的事务ID，去和每条数据的xmin、xmax这两个“身份证”进行比较,快速地判断出你应该看到哪个版本的数据：

你应该能看到那些“出版日期”（xmin）在你开始阅读之前，并且还没有被“下架”（xmax为空）或者“下架日期”（xmax）在你开始阅读之后的数据版本。
这样，即使别人正在修改或删除数据，他操作的只是他那个时间点之后的“副本”，你依然能看到你开始阅读时就已经存在的、一致的数据快照，这就实现了读不会阻塞写，写也不会阻塞读，大家各干各的,效率非常高。

书架越来越满怎么办？——勤劳的“清道夫”

你可能会想，老是添加新版本，旧版本又不删，那数据库岂不是会爆炸？确实，这会占用更多空间，所以PostgreSQL安排了一个后台进程，叫做 “自动清理”（Autovacuum） （来源：PostgreSQL管理文档）。

这个进程就像个勤劳的图书馆管理员，它会定期巡视书架，检查哪些旧版本的数据书已经没有任何人在引用了（所有开始阅读时间晚于该书“下架日期”的事务都结束了），它就会放心地把这些废弃的旧版本数据清理掉，腾出空间，这个机制至关重要，它保证了MVCC在享受高并发好处的同时,不会让存储空间无限增长。

怎么保证修改不出错？——严格的“提交规则”

那当多个人同时要修改同一本书（同一条数据）时，怎么保证不乱呢？这靠的是事务提交的原子性和锁机制。

两个人几乎同时想把张三的年龄从20岁改成21岁和22岁，MVCC会确保，同一时间，只能有一个人成功地对“当前最新版本”的数据进行修改（通过一种轻量级的锁机制），假设改成21岁的事务先发生，它会先创建出版本21岁，并标记版本20岁为作废，那么那个想改成22岁的事务，在开始时看到的还是20岁的版本，但当它试图修改时，会发现20岁的版本已经被别人标记为“正在修改”或“已作废”了，这时，它会有不同的处理策略（比如等待前者完成，或者直接报错）,这就避免了出现一个既像21岁又像22岁的混乱结果。

总结一下MVCC怎么保证数据不乱套：