PostgreSQL VACUUM激进回收

PostgreSQL 的 VACUUM 操作并非只有一种温和的模式。当数据库检测到某些表存在大量死元组，并且这些死元组占用了远超阈值的空间时，它会触发一种被称为“激进回收”的机制。简单来说，普通 VACUUM 可能只清理表尾部的页面并截断文件，而激进回收会扫描所有未被完全冻结的页面，哪怕这些页面里只有一条死元组，它也要硬着头皮去清理。这种机制的核心目标只有一个：防止事务 ID 回卷，同时尽可能回收空间，避免表无限膨胀。

很多人对激进回收的认知存在误区，认为它只是“更耗资源的 VACUUM”。实际上，它是 PostgreSQL 为了防止数据库因事务 ID 耗尽而强制关闭所设置的最后一道防线。理解它的触发逻辑、内部运作机制以及如何通过参数调优来驾驭它，是 DBA 从入门到精深的必经之路。

PostgreSQL 通过两个核心参数来控制激进回收的触发门槛：autovacuum_vacuum_insert_threshold 和 autovacuum_vacuum_insert_scale_factor。但真正决定是否进入“激进”模式的，是系统对“可见性地图”失效页面的统计。当一张表自上次 VACUUM 以来，被修改或新增的元组数量超过了特定公式计算出的阈值，自动清理守护进程就会启动，并标记为激进模式。

具体的计算公式如下：

vacuum insert threshold = autovacuum_vacuum_insert_threshold 
                        + autovacuum_vacuum_insert_scale_factor * reltuples

假设一张表有 1000 万行，autovacuum_vacuum_insert_scale_factor 为默认的 0.2，autovacuum_vacuum_insert_threshold 为 1000。那么阈值就是 1000 + 0.2 * 10,000,000 = 2,001,000。一旦插入或更新导致的死元组超过 200 万，普通 VACUUM 可能就不够用了，系统会倾向于执行激进回收。但这里有一个关键的区分点：即使触发了自动清理，如果表没有达到“防止事务回卷”的年龄限制，它可能只是普通的 VACUUM。真正的激进回收，往往伴随着冻结操作，也就是将老旧的事务 ID 替换为特殊的冻结 ID。

激进回收最硬核的部分在于它处理事务 ID 回卷的方式。PostgreSQL 的事务 ID 是 32 位的，最多容纳约 20 亿个事务。当剩余未使用的事务 ID 低于某个水位线时，数据库会进入“防回卷”模式。此时，VACUUM 必须是激进的。参数 autovacuum_freeze_max_age 决定了这个水位线，默认值为 2 亿。一旦某个表的年龄（即当前事务 ID 与表中最老元组事务 ID 的差值）达到这个值，自动清理进程会无视任何代价，强制对该表进行激进回收。

在这种模式下，VACUUM 会扫描所有未被标记为“全冻结”的页面。它不仅要清理死元组，还要将那些虽然还活着但事务 ID 太老的元组进行冻结。冻结操作会修改元组头，产生新的 WAL 日志，这是激进回收产生大量 I/O 和 WAL 流量的根源。如果你在监控中看到 WAL 写入量突然飙升，且伴随某个表的全表扫描，大概率就是激进回收正在冻结老旧的元组。

普通 VACUUM 之所以高效，是因为它利用了可见性地图。如果一个数据页面在可见性地图中被标记为“全可见”，且不需要冻结，VACUUM 可以直接跳过该页面，完全不读取。但激进回收会直接忽略可见性地图中关于“全可见”的标记，强行读取这些页面。原因很简单：这些页面虽然目前全可见，但里面可能包含非常古老的事务 ID，如果不及时冻结，很快就会导致回卷。因此，激进回收必须检查每一个可能包含未冻结元组的页面。

这种绕过行为直接导致了 I/O 的剧烈波动。原本只需要读取少量死元组页面的操作，瞬间变成了几乎全表扫描。对于大表，尤其是那些平时写入不频繁、数据相对静态的大表，激进回收一旦触发，可能会持续数小时甚至数天。这期间，磁盘读 I/O 会持续高负载，CPU 也会因为需要处理冻结逻辑和 WAL 生成而居高不下。

不要依赖猜测，直接查询系统视图。可以通过 pg_stat_progress_vacuum 视图实时观察 VACUUM 的状态。当看到 phase 字段显示为 scanning heap，且 vacuum_count 和 max_dead_tuples 等指标异常时，需要结合年龄来判断。更直接的方法是查询 pg_stat_activity 中 VACUUM 操作的等待事件。如果等待事件集中在 DataFileRead，并且查询语句是自动清理进程发出的，同时该表在 pg_class 中的 relfrozenxid 非常古老，那基本可以断定是激进回收。

另一个容易被忽视的指标是磁盘空间的变化。普通 VACUUM 通常不会释放空间给操作系统，除非在尾部截断。但激进回收配合 VACUUM FULL 或者更激进的 pg_repack 思路不同。激进回收本身不锁表，它只是把页面内的死元组空间标记为可重用，但文件大小不会缩小。如果你发现表文件大小没有变化，但死元组数量急剧下降，同时 I/O 飙升，这也是激进回收的典型特征。

要控制激进回收的破坏力，不能只靠禁用自动清理，那会导致数据库崩溃。正确的做法是调整触发门槛和资源限制。首先，对于大表，可以单独设置存储参数。例如，对于一张 100GB 的表，可以设置 autovacuum_vacuum_scale_factor = 0.01 而不是默认的 0.2，让普通 VACUUM 更频繁地运行，避免死元组积压到触发激进回收的程度。同时，降低 autovacuum_freeze_max_age 到 1 亿甚至更低，让冻结操作分散到多次普通 VACUUM 中完成，而不是积攒到一次激进回收中爆发。

其次，通过 autovacuum_work_mem 来提升 VACUUM 的内存使用量。默认只有 64MB，如果死元组太多，VACUUM 需要多次扫描索引，导致速度极慢。将这个值提高到 1GB 或更高，可以让 VACUUM 在内存中维护更大的死元组列表，减少索引扫描次数。但这会占用服务器内存，需要根据物理内存余量谨慎设置。

最后，考虑手动干预。在业务低峰期，对年龄较大的表执行 VACUUM FREEZE。这条命令会强制扫描全表并冻结所有符合条件的元组，虽然它本身就是一次人为触发的激进回收，但你可以控制它的执行时间，避免在业务高峰期自动触发。手动执行时，可以配合 vacuum_cost_delay 等代价参数来限制其 I/O 速率，但这会延长执行时间，需要在紧急程度和资源消耗之间权衡。

激进回收不仅扫表，还要扫索引。它需要从索引中删除指向死元组的索引条目。如果表上有多个索引，且死元组分布广泛，VACUUM 需要遍历所有索引，这会导致索引本身产生大量的随机读。更糟糕的是，频繁的索引扫描和删除操作可能加剧索引膨胀。死元组被清理后，索引页中留下了大量空闲空间，这些空间很难被有效重用，导致索引体积不断增长。

解决这个问题的关键在于减少死元组的产生。从业务层面看，避免长事务是首要任务。一个持续运行了 12 小时未提交的事务，会导致在这期间产生的所有死元组都无法被清理，即使是最激进的 VACUUM 也无能为力。监控 pg_stat_activity 中 xact_start 时间过早的连接，及时终止这些长事务，是比调优 VACUUM 参数更根本的解决方案。另外，合理使用 REINDEX CONCURRENTLY 在业务低峰期重建索引，可以消除已经产生的索引膨胀，让激进回收跑得更快。

对于单表体积达到 TB 级别的超大型表，单纯依靠参数调优已经难以根除激进回收带来的性能尖刺。分区表是更优雅的架构级解决方案。将大表按时间或业务维度拆分成多个子表后，每个子表的年龄和死元组数量都是独立计算的。自动清理进程可以独立地对各个分区进行 VACUUM，即使是激进回收，也只会锁定单个分区，而不是整张大表。

更重要的是，对于按时间分区的表，历史分区往往不再有写入操作。对于这些静态分区，可以手动执行一次 VACUUM FREEZE，然后将其设置为只读，甚至直接分离。这样一来，数据库永远不需要再对这些分区执行激进回收，从根本上消除了 I/O 风暴的隐患。这是处理海量数据时最彻底的优化手段，也是资深 DBA 与普通使用者的分水岭。

不要等到数据库因为回卷风险而强制进入只读模式才采取行动。建立一套针对表年龄的监控体系至关重要。定期执行以下查询，获取每个数据库中最老的事务年龄：

SELECT datname, age(datfrozenxid) FROM pg_database;

对于单个表，查询 pg_class 中的 relfrozenxid 年龄：

SELECT relname, age(relfrozenxid) 
FROM pg_class 
WHERE relkind = 'r' 
ORDER BY age(relfrozenxid) DESC 
LIMIT 10;

当年龄接近 autovacuum_freeze_max_age 的 80% 时，就应该发出告警并准备手动干预。同时，监控 pg_stat_user_tables 中的 n_dead_tup 和 n_live_tup 比例。如果死元组比例超过 20%，说明普通 VACUUM 的频率或效率已经跟不上写入速度，需要调整该表的自动清理参数。将激进回收扼杀在摇篮中，远比等它爆发后再去救火要轻松得多。

激进回收是 PostgreSQL 为了数据一致性和系统可用性所设计的必要机制，但它确实会对生产环境造成冲击。理解它的触发条件、冻结逻辑以及可见性地图的绕过原理，结合合理的参数配置、长事务治理和分区架构，完全可以将这种冲击控制在可接受的范围内，甚至让用户对它的发生毫无感知。