一、核心概念概述
PostgreSQL 采用 MVCC（多版本并发控制）机制，实现：
- 读写不阻塞
- 数据一致性隔离
- 提高并发性能
核心思想：同一条记录在不同时刻会产生多个版本，查询根据事务快照选择"可见版本"
二、核心数据结构
每一元组（Tuple）包含关键隐藏字段：
|
字段
|
含义
|
|
xmin
|
创建该版本的事务ID
|
|
xmax
|
删除/更新该版本的事务ID
|
|
tuple version
|
数据的一个历史状态
|
执行 UPDATE test SET name='C' WHERE id=1，版本演化结果：
|
版本
|
xmin
|
xmax
|
name
|
|
A
|
100
|
200
|
A
|
|
B
|
200
|
300
|
B
|
|
C
|
300
|
NULL
|
C
|
关键理解
- 每一次 UPDATE = 产生一个新版本
- 老版本通过 xmax 标记“被替换”
- 当前版本通过 xmax = NULL 表示“仍然有效”
三、事务快照（Snapshot）
每个事务执行时都会生成快照，这一点和MySQL一样：
|
字段
|
含义
|
|
xmin
|
当前最小活跃事务ID
|
|
xmax
|
当前最大活跃事务 ID + 1
|
|
xip[]
|
活跃事务列表
|
四、MVCC 可见性判断规则
判断一个版本是否可见，本质是：
- xmin 已提交
- xmax 未提交 或未发生
- 不属于当前 xip 冲突事务
五、Freeze 原理
Freeze = 把 tuple 的 xmin 从普通事务ID改成 FrozenXID，让它"永远可见"
5.1 为什么必须要 Freeze
PostgreSQL 每一行都有：
- xmin：创建该行的事务ID
- xmax：删除/更新该行的事务ID
事务ID是 32位循环的（会回绕）假设：
- 老数据 xmin = 10
- 当前事务ID = 4,000,000,000
由于回绕：PostgreSQL 可能会误判：xmin=10 是“未来事务”（非常危险）
5.2 Freeze 的解决方案
把：xmin = 10变成：xmin = FrozenXID (通常是2)
效果：
- 永远可见
- 不再参与事务可见性判断
- 不受回绕影响
5.3 Freeze 具体做了什么
当执行 Freeze 时：
- 扫描表（heap）
- 找到老 tuple（xmin 很旧）
- 修改：xmin → FrozenXID
- 设置 hint bits（减少后续判断成本）
5.4 Freeze 触发机制
自动触发（autovacuum）
- autovacuum_freeze_max_age（默认 200M）当数据库接近这个值，会触发 强制 vacuum freeze
- vacuum_freeze_table_age控制表达到多少年龄开始 freeze
- vacuum_freeze_min_age控制多老的 tuple 才允许被冻结
5.4 强制 Freeze（防止数据库挂掉）
如果接近极限（≈ 2^31），PostgreSQL 会停止写入，报错：database is not accepting commands to avoid wraparound data loss，此时必须立即：VACUUM FREEZE;
5.5 Freeze 的两种模式
普通 Freeze（lazy vacuum）
特点：
- 只处理部分页面
- 受 visibility map 控制
- 性能影响小
Aggressive Freeze（激进）
触发条件：
- 接近 autovacuum_freeze_max_age
特点：
- 全表扫描
- 忽略 visibility map
- IO 很重
六、Visibility Map（VM，可见性映射）
6.1 VM 的作用
VM 记录每个数据页（page）的状态：
|
标记
|
含义
|
|
all-visible
|
页面所有 tuple 对所有事务可见
|
|
all-frozen
|
页面数据已冻结（Freeze 完成）
|
6.2 优化作用一：跳过 MVCC 判断
如果 page = all-visible： 查询可直接返回数据，无需逐条检查：xmin，xmax和xip
6.3 优化作用二：Index-Only Scan
当满足以下条件：
- 查询字段全部在索引中
- 对应 page 被标记为 all-visible
PostgreSQL 可以执行：Index-Only Scan
例子：SELECT name FROM test WHERE id = 1;
优化前：
- 访问 index + heap
- 做 MVCC 判断
优化后（Index-Only Scan）：
- 仅访问 index
- 不访问 heap
- 不做 tuple 可见性判断
七、完整执行流程
执行：SELECT name FROM test WHERE id = 1; 流程如下：
- 获取事务快照（xmin / xmax / xip）
- 通过索引定位数据
-
检查 Visibility Map
- all-visible → 直接返回
-
否则进入 MVCC 判断
-
MVCC 判断
- 基于 xmin 判断是否存在
- 基于 xmax 判断是否仍有效
- 基于 xip 判断事务冲突
-
- 返回最终版本
-
后台优化
- VACUUM 清理旧版本
- Freeze 防止 XID 回绕
- VM 持续提升 Index-Only Scan 命中率