回收与持久化：VACUUM、冻结、WAL

第 2 章留下两个悬而未决的问题：堆里那些再没人能看到的旧版本（死元组）谁来清？以及，xmin/xmax 这些事务 ID 是有限的 32 位整数，用完了会怎样？这一章给出 PG 的两个答案——VACUUM（兼管回收与冻结）和 WAL（兼管持久与恢复）。前者是 MVCC 的后勤部队，把「为并发把清理后移」这笔账按时结掉；后者是另一条独立的主线——它不解决可见性，而是回答「机器断电的那一刻，已提交的数据凭什么还在」。两条线在本章交汇：VACUUM 决定数据库能不能长期健康运行，WAL 决定它能不能在崩溃后原样醒来。

§1普通 VACUUM：原地标记可复用，不还盘

普通 VACUUM 扫描表，把死元组的空间在 free space map 里标为可复用，不加排他锁、不缩小文件。

普通 VACUUM（不带 FULL）做的事，可以拆成三个动作：

• 找死元组。 扫描表的各个 Page，对每个 tuple 用「最老仍在运行的事务」做判定：若这个版本连最老的事务都看不到了，它就是死元组，可以回收。
• 标记空间可复用。 死元组占的槽位被释放，其空间登记进该表的 free space map（FSM，空闲空间图）。后续 INSERT/UPDATE 找落脚点时会查 FSM，把新版本塞进这些被腾出的空洞。
• 顺带维护索引与可见性图。 清理指向死元组的索引项，并更新 可见性图（§4）。

两个关键事实，必须钉死：

其一，普通 VACUUM 不加排他锁。 它只取一个较弱的锁（SHARE UPDATE EXCLUSIVE），允许并发的 SELECT/INSERT/UPDATE/DELETE 继续跑——它和业务读写共存，这正是它能作为日常后台任务（§2 的 autovacuum）不停运行的前提。

其二，普通 VACUUM 不把文件还给操作系统。 死元组的空间被标为「内部可复用」，但表文件的总大小（高水位线）不下降。从操作系统看，这张表占的磁盘一个字节都没少；省下的空间只是被 PG 留作内部周转。

底层机制（比文档深一层）。 为什么普通 VACUUM 宁可不还盘？因为还盘要付两笔它不愿付的代价。第一，把文件尾部缩短需要保证尾部的 Page 全空，这往往要先把存活 tuple 从尾部搬到前面的空洞里——搬数据就得改它们的物理位置，进而要更新所有指向它们的索引，开销直逼重写。第二，绝大多数表的大小是波动的：今天清出 200MB 空闲，明天的写入又会把它填回去；现在费力还给 OS、明天再向 OS 申请，等于做了两趟无用功，中间还会引发文件系统层的碎片。于是 PG 的判断是：把空闲留在表内周转，是比「还盘—再申请」更省的稳态。只有当一张表确实一次性清出了大量、且预期不会再涨回去的空间时，归还才划算——那时才动用 §3 的 VACUUM FULL 或 pg_repack。这条「轻量回收是常态、还盘是例外」的取舍，是理解 PG 运维的第一性原理。

§2autovacuum：什么时候自动触发

后台进程按「死元组数超过阈值 + 比例」自动触发 VACUUM，并按比例顺带触发 ANALYZE。

对一张表，autovacuum 触发 VACUUM 的判据是一个阈值公式。当该表的死元组数（n_dead_tup）超过下面这个动态阈值，就触发：

触发阈值 = autovacuum_vacuum_threshold          -- 默认 50
         + autovacuum_vacuum_scale_factor       -- 默认 0.2
         × reltuples                            -- 该表的估算总行数

-- 例：一张 100 万行的表
--   阈值 = 50 + 0.2 × 1,000,000 = 200,050 个死元组

常数项 autovacuum_vacuum_threshold（默认 50）是给小表兜底的下限；比例项 autovacuum_vacuum_scale_factor（默认 0.2）让阈值随表规模线性放大——一张百万行的表，要攒到约 20 万死元组才会被清。这个设计避免了大表上 autovacuum 过于频繁，但也埋了一个尾巴：超大表的 0.2 比例意味着要积累海量死元组才触发，常需手工把这两个参数按表调小。

同一套机制还驱动 ANALYZE。autovacuum 按一个并行的公式（autovacuum_analyze_threshold 默认 50、autovacuum_analyze_scale_factor 默认 0.1，乘以表的变更行数）触发 ANALYZE，重新采样、更新该表的统计信息。统计信息是查询规划器估算行数与代价的依据——它准不准，直接决定规划器选对还是选错执行计划（这条链留到 第 5 章 §统计信息展开）。所以 autovacuum 实际上一岗双责：既维护物理健康（回收），又维护规划健康（统计）。

§3VACUUM FULL：重写整表，把空间还给 OS

VACUUM FULL 把整表重写进一个新文件、加全表排他锁，是唯一能把磁盘真正还给操作系统的内置方式。

VACUUM FULL 的机制与普通 VACUUM 完全不同：它不是「就地标记」，而是把整张表的存活 tuple 逐个搬进一个全新的文件，新文件紧凑无空洞、索引一并重建，然后用新文件替换旧文件、把旧文件交还操作系统。三个直接后果：

• 加 ACCESS EXCLUSIVE 锁——全表阻塞。 这是 PG 最强的表级锁，重写期间该表的所有读和写全部被挡在门外。表越大，阻塞越久。
• 临时占用接近双倍磁盘。 重写过程中新旧两个文件同时存在，峰值磁盘占用约为表体积的两倍；磁盘紧张时这本身就会让操作失败。
• 结束后磁盘真正下降。 旧文件释放后，操作系统看到的占用随之回落——这是普通 VACUUM 做不到的。

底层机制（比文档深一层）。 VACUUM FULL 与普通 VACUUM 的分野，本质是「就地标记 vs 整体搬迁」两种回收哲学的代价分配。就地标记（普通）把成本压到最低、可在线运行，但永远换不来文件收缩；整体搬迁（FULL）能换来收缩，但搬迁必然要冻结全表、且过程中双份占用。生产环境里 VACUUM FULL 的全表锁往往不可接受，因此社区的事实标准是扩展 pg_repack：它在线重建表（用触发器捕获重写期间的增量改动，最后只在极短的切换瞬间持锁），达到「收缩文件」的效果而几乎不阻塞业务。结论：VACUUM FULL 是「能还盘但要停服」的内置兜底，pg_repack 是「能还盘且基本不停服」的生产首选——但两者都只在「确实需要还盘」这个例外场景出场，日常仍靠 autovacuum。

§4冻结：把老版本标为永远可见

VACUUM 把足够老的版本的 xmin 改写为「已冻结」，使其对所有未来事务永久可见。

机制本身不复杂：VACUUM 在扫描时，对那些 xmin 对应的事务已经老到「早于所有仍在运行的事务」的 tuple，把它的状态标记为 frozen（已冻结）。被冻结的 tuple 在可见性判定时被无条件视为「其创建事务已提交、对所有人可见」，不再去比 xmin 的数值。冻结信息记录在 tuple 头的标志位里（现代 PG 用 xmin 的提交标志位表达，无需真的改写 xmin 的数值，但效果等价于「永久可见」）。

这一节和 §5 是同一个问题的两面：冻结是手段，回卷是它要防的灾难。 先把手段记牢——「老到一定程度的版本会被冻结成永久可见」，§5 解释不冻结会塌方成什么样。

§5事务 ID 回卷：不冻结，老数据会消失

事务 ID 是 32 位、约 21 亿个可见范围后绕回；不及时冻结，回卷会让老行突然不可见。

事务 ID（txid）是 32 位无符号整数。但 PG 的可见性判定不是用整个 2³² 空间，而是用环形比较：对任意一个事务，「过去」是它之前的约 2³¹（约 21 亿）个 ID，「未来」是它之后的约 2³¹ 个 ID。整个 ID 空间被想象成一个环，每个事务站在环上某点，一半环是它的过去、一半是未来。

问题来了：随着新事务不断分配，这个「当前点」沿环移动。一个 tuple 的 xmin 固定不动，但「当前点」在追它。当当前点绕环走了超过 2³¹，那个老 xmin 就从「在当前点过去 21 亿以内」滑进了「在当前点未来一侧」——它会突然显得像是「一个尚未发生的未来事务创建的」，于是对当前所有事务都不可见。那一行数据明明还在磁盘上，却再也查不出来，看起来像凭空消失。

底层机制（比文档深一层）。 PG 用两道防线把回卷挡在门外，且越逼近上限手段越激进。第一道：每张表的 pg_class 里记着一个 relfrozenxid——「这张表里最老的、尚未冻结的 xmin」。一个数据库的回卷风险，由全库最老的那个 relfrozenxid 决定，用 age(datfrozenxid) 度量（这个 age 离 2³¹ 越近越危险，§9 会亲手查它）。第二道：当某张表的年龄超过 autovacuum_freeze_max_age（默认 2 亿）时，PG 会对它强制发起一次 anti-wraparound（防回卷）autovacuum——这种 VACUUM 即使你关闭了 autovacuum 也照常运行，专门去推进 relfrozenxid、冻结老行。若连这道防线都被无视，年龄逼近硬上限时，PG 会进入自保模式：停止接受新的写入事务（只读、报错要求手动 VACUUM），以阻止年龄继续增长、用拒绝服务来保住数据正确性。结论：「数据库突然只读、报 wraparound 警告」不是故障，是 PG 用停摆换数据不丢的最后手段——而触发它的根因，几乎总是 autovacuum 长期没跟上。

§6可见性图：回收与查询共用的枢纽

可见性图给每个 Page 两位，标记 all-visible / all-frozen；VACUUM 据它跳页，index-only scan 据它免回堆。

可见性图（Visibility Map，VM）是每张表附带的一个紧凑位图，给表的每个 Page 分配两个 bit：

• all-visible 位： 置位表示「这个 Page 里的所有 tuple，对所有当前事务都可见」——即页内没有任何死元组、也没有任何正在被某事务改动的版本。
• all-frozen 位： 置位表示「这个 Page 里的所有 tuple 都已冻结」——这个 Page 在下一轮防回卷 VACUUM 里可以被直接跳过，无须再检查冻结。

VACUUM 一边清理一边维护这两个位：清完一个全是存活、无人改动的 Page，就给它置上 all-visible；若页内全部冻结，再置上 all-frozen。反过来，下一次 VACUUM 扫描时，遇到 all-visible 的 Page 直接跳过——因为它保证没有死元组可清。这就是为什么「第二次 VACUUM 比第一次快得多」：大量页被 VM 短路掉了。任何对某 Page 的写入（INSERT/UPDATE/DELETE）会清掉该页的 all-visible 位，标记它「又脏了，下次得重新检查」。

底层机制（比文档深一层）。 VM 的精妙在于它是连接「回收」与「查询加速」两条主线的同一个枢纽。回收侧的用法上面讲过；查询侧的用法是 index-only scan（仅索引扫描）：当一个查询要的列全在某索引里，规划器本可以只读索引、不回堆——但 MVCC 的麻烦在于，索引项不携带可见性信息，光看索引无法判断这一行对当前事务是否可见，似乎不得不回堆查 xmin/xmax。VM 一举解决了它：扫到一个索引项，先查它指向的 Page 在 VM 里是否 all-visible——若是，则整页都可见，这一行必然可见，于是跳过回堆，直接用索引里的值返回。一份为回收而生的元数据，反手成了查询免回堆的关键。这条「VM → index-only scan」的链，是第 4 章索引性能的核心前提，留到 第 4 章 §仅索引扫描详述。结论：VACUUM 不只是在「打扫卫生」——它每清干净一个 Page 并置上 all-visible，就同时为查询省下了一次回堆。回收做得勤，查询也跟着快，这是同一份 VM 的两头红利。

§7WAL：先写日志，再改数据

改任何数据页之前，先把该变更的 redo 记录顺序写入 WAL；崩溃后重放 WAL 即可恢复——这就是持久性的来源。

WAL（Write-Ahead Logging，预写日志）的规则只有一句，却是整个持久性的地基：在修改任何数据 Page 之前，必须先把描述这次修改的 redo 记录，顺序追加写入 WAL，并保证 WAL 已落盘。 数据页本身可以稍后再异步刷盘；但只要 WAL 里记下了「这个 Page 该怎么改」，就够了。崩溃后，PG 从某个已知一致点开始，把 WAL 里的 redo 记录逐条重放（redo / roll-forward），把所有「日志记了、但数据页还没落盘」的改动重新施加一遍，数据库就恢复到崩溃前的一致状态。

底层机制（比文档深一层）。 WAL 的全部威力，来自一次「随机写换顺序写」的交易。数据页散布在表文件各处，刷它们是随机 I/O——磁头乱跳、SSD 写放大，又慢又贵。WAL 则是一个只追加的顺序日志，写它是顺序 I/O——机械盘上是连续磁道、SSD 上也对写入友好，快上一两个数量级。WAL 协议把这两者的代价做了置换：把昂贵的随机写（刷数据页）推迟、批量、异步化，只要求廉价的顺序写（append WAL）在 COMMIT 前同步落盘。于是 COMMIT 的延迟只取决于一次顺序 fsync，而非一堆随机刷盘。换句话说，持久性的成本被从「每次提交刷一堆随机页」压缩成了「每次提交追加一段顺序日志」——这是 WAL 既保证不丢、又不拖垮吞吐的根本原因，也是几乎所有现代数据库（含 InnoDB 的 redo log）共用的设计。

§8检查点：把脏页刷干净、缩短恢复距离

检查点把截至某 WAL 位置的脏页全部刷盘，之后该位置前的 WAL 可回收，恢复也只需从此点重放。

一次检查点（checkpoint）做两件事：把当前所有脏页（已被改、还没刷盘的 Page）刷到数据文件，并在 WAL 里记下一条检查点记录、标明「截至这个 WAL 位置（LSN）的改动均已落盘」。完成后两个收益立刻兑现：

• WAL 可回收。 这个检查点位置之前的 WAL 段不再为「崩溃恢复」所需（仍会为复制/归档保留），可以被回收或归档，WAL 占用不再无限增长。
• 恢复距离缩短。 下次崩溃恢复只需从最近一个检查点开始重放，而非从远古的某条记录——检查点越频繁，恢复越快。

检查点由时间（checkpoint_timeout）或 WAL 量（max_wal_size）触发，二者先到先发。这里有个张力：检查点太稀，恢复慢、WAL 堆积；太频，则刷盘 I/O 尖峰频繁、且推高下面 §9 全页写的开销。checkpoint_completion_target 把一次检查点的刷盘摊薄到整个区间里、削平 I/O 尖峰，是这个张力的主要调节钮。

§9全页写：防住撕裂的页

每个检查点后某页第一次被改时，把整页镜像写进 WAL，以防操作系统只写了半个 8KB 页（torn page）。

全页写（full-page writes，FPW）的规则：在每次检查点之后，某个 Page 第一次被修改时，PG 不只写增量 redo 记录，而是把这一整个 8KB Page 的镜像完整写进 WAL。同一个检查点周期内，这个 Page 后续再被改，就只写增量了（因为镜像已经在 WAL 里有一份）。

恢复时这样用：重放 WAL 遇到某个 Page 的全页镜像，就用这个完整镜像直接覆盖磁盘上那个或已撕裂的页——无论磁盘上的版本是否半写损坏，都被一个已知完整的镜像替换掉，撕裂被抹平；之后的增量记录再安全地叠加上去。代价很直接：每次检查点之后的一段时间，WAL 量会显著上升（每个被首次触碰的 Page 都要塞进一整页 8KB），这也是检查点不能太频繁的原因之一——检查点越密，「检查点后首次修改」发生得越频繁，全页写的 WAL 膨胀就越严重。

§10崩溃恢复与 WAL 的其它去处

崩溃恢复 = 从最近检查点重放 WAL 到末尾；同一份 WAL 还驱动流复制与逻辑解码。

崩溃恢复是 WAL 的本职：进程重启后，PG 找到最近的检查点记录，从那个 WAL 位置开始顺序重放每一条 redo 记录直到 WAL 末尾，途中用全页镜像修复撕裂页、用增量记录重做改动，最终把数据库带回崩溃前的一致状态。已提交的事务（WAL 已落盘）必然被恢复，未提交的事务的改动则不会出现在最终状态里。

同一份 WAL 流还有两个重要去处，二者由 wal_level 参数控制粒度：

• 物理流复制（streaming replication）。 主库把 WAL 实时发给一个或多个 standby，standby 持续重放这份 WAL，从而在物理层面（同样的 Page、同样的字节）紧紧跟随主库。这就是 PG 高可用的主力——standby 随时能接替主库，因为它一直在重放主库的 WAL。
• 逻辑解码（logical decoding）。 当 wal_level = logical 时，WAL 里被额外记入足够的信息，使其可以被解码成「逻辑层面的行变更」（哪张表、哪行、INSERT/UPDATE/DELETE 成什么），而非物理字节。这就是 PG 做 CDC（变更数据捕获）和逻辑复制的基础——下游可以只订阅自己关心的表、甚至跨大版本复制。

从崩溃恢复，到物理高可用，再到逻辑 CDC，同一条 WAL 日志流服务了三层完全不同的需求——这正是「先写日志」这条朴素规则被反复复用的回报。

§11动手观察：从膨胀到回收，再看回卷年龄

把回收线拧成一个可观察的实验：制造膨胀、量它、跑普通 VACUUM 看磁盘没变小、再跑 VACUUM FULL 看文件缩小，最后查全库的回卷年龄。下面的输出未在本机执行（具体数值因实例与版本而异），用于演示该看哪些字段、它们如何变化。

-- 0) 造一张表，灌 100 万行
CREATE TABLE t (id int PRIMARY KEY, v int);
INSERT INTO t SELECT g, g FROM generate_series(1, 1000000) g;

-- 1) 大量更新：每行都被改一次 → 产生 100 万个旧版本（死元组）
UPDATE t SET v = v + 1;

-- 2) 量死元组与膨胀
SELECT n_dead_tup, n_live_tup
  FROM pg_stat_user_tables WHERE relname = 't';
--  n_dead_tup | n_live_tup
-- ------------+------------
--    1000000  |   1000000        <- 未在本机执行：死活元组各 100 万

SELECT pg_size_pretty(pg_relation_size('t'));
--  pg_size_pretty
-- ----------------
--  69 MB                          <- 未在本机执行：约翻倍（本应 ~35MB）

-- 3) 普通 VACUUM：标记死元组空间可复用，但不还盘
VACUUM (VERBOSE) t;
--  ... tuples: 1000000 removed, 1000000 remain ...   <- 死元组被标可复用

-- 4) 再看大小 —— 没变！空间被留作内部周转，未还给 OS
SELECT pg_size_pretty(pg_relation_size('t'));
--  pg_size_pretty
-- ----------------
--  69 MB                          <- 未在本机执行：仍占盘，符合预期

-- 5) VACUUM FULL：重写整表到新文件 → 文件真正缩小（全表锁）
VACUUM FULL t;
SELECT pg_size_pretty(pg_relation_size('t'));
--  pg_size_pretty
-- ----------------
--  35 MB                          <- 未在本机执行：还盘后回落

-- 6) 全库回卷年龄：age 越大越逼近 2^31 危险线
SELECT datname, age(datfrozenxid) AS xid_age
  FROM pg_database ORDER BY xid_age DESC;
--   datname  | xid_age
-- -----------+----------
--  appdb     | 48213004              <- 未在本机执行：离 ~21 亿尚远
--  postgres  |   312900

逐行解读，把每个观察值映射回概念：

• 步骤 1 UPDATE 全表一条 UPDATE 改了全部 100 万行——按第 2 章的因果，这不是原地改，而是写了 100 万个新版本，留下 100 万个旧版本即死元组。膨胀就此产生。
• 步骤 2 n_dead_tuppg_stat_user_tables 的 n_dead_tup 直接量出死元组数。它正是 §2 autovacuum 阈值公式的输入——这个值越过阈值，autovacuum 就会来清。
• 步骤 2 表约翻倍pg_relation_size 显示约 69MB——本应约 35MB 的表因死元组占用而近乎翻倍。这就是膨胀在磁盘上的样子。
• 步骤 3–4 VACUUM 后大小不变普通 VACUUM 报告「1000000 removed」——死元组确实被处理了（空间进入 FSM 可复用），但第 4 步的 pg_relation_size 仍是 69MB。这是 §1 的核心结论的现场：标记可复用 ≠ 还盘。
• 步骤 5 VACUUM FULL 后缩小VACUUM FULL 把表重写进新文件，磁盘回落到约 35MB——磁盘真正下降。代价是这条命令期间全表被 ACCESS EXCLUSIVE 锁挡住（§3）。
• 步骤 6 age(datfrozenxid)age(datfrozenxid) 是每个数据库距「最老未冻结事务」的年龄，越大越逼近 2³¹ 的回卷红线（§5）。日常该监控全库最大的这个 age；它若持续上涨且接近 autovacuum_freeze_max_age，说明冻结没跟上。