MVCC 与 VACUUM:每次写都在留下旧版本

4.1核心观念:每次写都留下旧版本

UPDATE 不原地修改,而是写入一个新行版本,旧版本变成死元组(dead tuple);DELETE 只是给行打上删除标记。

每个行版本(tuple)在堆里都带两个隐藏的系统字段:

• xmin:创建这个版本的事务 ID(XID)。
• xmax:删除或取代这个版本的事务 ID;若该版本还"活着",xmax 为 0。

于是同一逻辑行的多个版本会在堆里共存:一次 UPDATE 把旧版本的 xmax 设为当前事务 ID,同时插入一个 xmin 为当前事务 ID 的新版本。DELETE 更简单——只设旧版本的 xmax,不插入新版本。真正的物理删除不在 DELETE 这一刻发生,而是后来由 VACUUM 完成。

4.2可见性:快照决定你看到哪个版本

每个事务按自己的快照,只看到 xmin 已提交且早于快照、且(xmax 未提交或晚于快照)的那个版本。

同一行有多个版本,一个事务该看到哪个?答案藏在它启动时(或语句开始时)拿到的一个快照里。快照记录了"此刻哪些事务已提交、哪些还在进行"。判定一个版本对当前事务是否可见,规则可以简化成两句:

• 它的 xmin 对应的事务已提交,且在当前事务的快照之前——这个版本对它"已经存在"。
• 它的 xmax 为空,或对应事务尚未提交 / 晚于当前快照——这个版本对它"还没被删"。

两条同时成立,这个版本才对当前事务可见。这正是 MVCC 的卖点:读不阻塞写、写不阻塞读——读事务沿着快照找到属于自己的旧版本,完全不必等正在改这一行的写事务提交。

死元组的精确定义

有了可见性规则,就能精确定义死元组(dead tuple):一个旧版本,如果对所有当前活跃事务都不再可见——也就是没有任何快照还需要它——它就是死元组,可以被安全回收。注意"对所有活跃事务"这个限定:只要还有一个老事务的快照仍能看到它,它就不是死元组,VACUUM 不能动它。

4.3VACUUM:回收死元组(并喂养优化器)

VACUUM 扫描表,把对所有事务都不可见的死元组占用的空间标记为可重用。

关键澄清:普通 VACUUM 不缩小文件

普通 VACUUM 把死元组占的空间标记为该表后续可重用(记进表的空闲空间映射 free space map)。同一张表之后的 INSERT / UPDATE 会优先填进这些空洞。但表的物理文件不会变小、空间不还给操作系统——磁盘占用维持在历史峰值。所以"删了一半数据,df 看磁盘却没降"不是 bug,是预期行为。

VACUUM 顺带做的三件事

除了回收空间,一次 VACUUM(或 autovacuum)还会:

• 更新统计信息(autovacuum 会捎带触发 ANALYZE)——直接喂养 第 02 章讲的优化器代价估算。VACUUM 跟不上,统计也容易跟不上,优化器就开始估错。
• 更新可见性映射(visibility map):把"整页都是对所有事务可见的活元组"的数据页标为 all-visible。第 03 章的 index-only scan 正是靠这个标记决定能不能免回表——页没被标 all-visible,index-only scan 就退化成要回堆。
• freeze 老行:把足够老的行版本标记为"对所有事务永远可见",防止事务 ID 回绕(§4.6)。

4.4HOT 更新:UPDATE 的省钱路径

如果一次 UPDATE 没有修改任何被索引的列、且当前堆页有空闲空间,新版本就放在同一页、且不新建任何索引项。

这条路径叫 HOT(Heap-Only Tuple)。回想 §4.1:普通 UPDATE 要插入新版本,并为每一个索引都加一条指向新版本的索引项——表上有 5 个索引,一次 UPDATE 就要动 5 个索引。HOT 把这笔开销省掉:新版本通过页内的一条指针链接到旧版本,索引项仍指向旧位置、顺着链就能找到新版本,因此无需触碰任何索引。

HOT 触发有两个硬条件,缺一不可:

• 这次 UPDATE 没有改任何被索引的列(改了 status,而 status 上没索引——可以;改了建有索引的 email——不行)。
• 旧版本所在的堆页还有空闲空间容纳新版本。

第二个条件给了一个可调旋钮:fillfactor。它让 PostgreSQL 在每个数据页里故意留白(默认表是 100,即填满;设成 90 表示每页只填 90%、留 10% 给后续更新)。频繁更新的表把 fillfactor 调到 90 左右,新版本更容易挤进同一页 → HOT 命中率上升。

-- 为高频更新的表留出页内空间,促成 HOT 更新
ALTER TABLE counters SET (fillfactor = 90);
-- 重写后生效(对已有数据)
VACUUM FULL counters;   -- 注意会锁表;或用 pg_repack

-- 观察 HOT 命中:n_tup_hot_upd 占 n_tup_upd 越高越好
SELECT relname, n_tup_upd, n_tup_hot_upd
FROM pg_stat_user_tables
WHERE relname = 'counters';

4.5表膨胀:诊断与处理

死元组堆积,使表和索引占用的空间远超实际有效数据,这就是膨胀(bloat)。

膨胀是前几节的必然产物:写产生死元组(§4.1),长事务或滞后的 autovacuum 让死元组清不掉(§4.2),而普通 VACUUM 又不缩小文件(§4.3)。结果是一张逻辑上只有 1GB 有效数据的表,物理上占了 5GB。

诊断:先看 pg_stat_user_tables

第一手信号来自系统视图 pg_stat_user_tables:n_dead_tup(死元组数)、n_live_tup(活元组数)、last_autovacuum(上次自动清理时间)。死元组占比高、且 last_autovacuum 很久以前(或为空),就是膨胀正在发生的直接证据。

SELECT relname,
       n_live_tup,
       n_dead_tup,
       round(n_dead_tup * 100.0 / nullif(n_live_tup + n_dead_tup, 0), 1) AS dead_pct,
       last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 5;

   relname   | n_live_tup | n_dead_tup | dead_pct |        last_autovacuum
-------------+------------+------------+----------+-------------------------------
 counters    |     120000 |    4830000 |    97.6  | 2026-05-30 02:11:09   -- 三天前
 orders      |    9800000 |     410000 |     4.0  | 2026-06-02 06:30:55
 audit_log   |   30000000 |        120 |     0.0  | 2026-06-02 07:01:12

• counters:活元组 12 万,死元组却有 483 万——dead_pct=97.6%。这张表 97% 以上的元组都是垃圾,且 last_autovacuum 停在三天前,autovacuum 明显没跟上。典型的高频更新计数器表膨胀(正是本章末尾挑战题的原型)。
• orders:死元组占比 4%、当天清过——健康。

需要精确的膨胀字节数(而非比例估计)时,装扩展 pgstattuple:SELECT * FROM pgstattuple('counters'); 会给出活/死元组的确切字节、空闲空间占比。

膨胀的后果:连回第 01 章的页读

膨胀不是"占点磁盘"那么轻。一张膨胀的表,同样的数据散落在更多的数据页里:

• 顺序扫描要读更多页:有效数据没变,但 Seq Scan 必须读完所有膨胀的页。这直接体现在 第 01 章 BUFFERS 的 read 数变大。
• 缓存命中率下降:页变多,shared_buffers 装不下,更多页要从磁盘读(连第 05 章)。
• 索引也膨胀:索引同样积累指向死元组的项,变大、变深,查找变慢。

处理:三个层次

• 治本:让 autovacuum 跟上(§4.6)。绝大多数膨胀的根因是 autovacuum 对这张表太迟钝,调参后稳态膨胀会回落到可接受区间。
• 已严重膨胀、需立刻回收磁盘:VACUUM FULL(锁表,停机窗口内用)或 pg_repack(在线、几乎不阻塞)。
• 设计层面:对天然高频更新的表,用 HOT 友好设计(§4.4)从源头减少死元组与索引维护。

4.6autovacuum 调优 + freeze/wraparound

autovacuum 是后台进程,按一条公式自动判断"这张表的死元组够多了,该清了"——公式默认值对大表偏迟钝,这是膨胀的头号配置原因。

触发公式

对每张表,autovacuum 在死元组数超过下面这个阈值时触发清理:

vacuum 触发阈值
  = autovacuum_vacuum_threshold              (默认 50)
  + autovacuum_vacuum_scale_factor (默认 0.2) × 表的行数(reltuples)

例:一张 1000 万行的表
  = 50 + 0.2 × 10,000,000
  = 2,000,050  → 要积累约 200 万死元组才触发一次 autovacuum

-- 对一张高频更新的大表,让 autovacuum 更积极
ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.01,   -- 1% 死元组就清,而非默认 20%
  autovacuum_vacuum_threshold    = 1000
);

freeze 与事务 ID wraparound

事务 ID(XID)是 32 位的,约 21 亿个值用完后会回绕(wraparound)归零。可见性判断依赖"当前 XID 与版本 xmin 的大小关系",一旦 XID 回绕,"过去"和"未来"会错乱,本该可见的老数据会突然变得不可见——这是会丢数据的灾难级故障。

防回绕的机制就是 freeze:VACUUM 把足够老的行版本标记为"已冻结",即对所有事务永远可见,从此不再参与 XID 大小比较,把它们"移出"回绕的威胁。参数 autovacuum_freeze_max_age(默认 2 亿)控制:一张表最老的未冻结 XID 距今超过这个年龄,就强制触发一次 freeze 用的 autovacuum——即使你把 autovacuum 关了也照样跑。

关键参数速查