什么是 VACUUM？为什么 PostgreSQL 必须执行 VACUUM 操作？

知识点图片

在 PostgreSQL 中，VACUUM（清理）是一个至关重要的数据库维护操作。要理解什么是 VACUUM 以及为什么必须执行它，我们需要先了解 PostgreSQL 底层的架构设计——MVCC（多版本并发控制）。

下面为您详细解答：

一、什么是 VACUUM？

简单来说，VACUUM 就像是 PostgreSQL 的“垃圾回收机制”（Garbage Collection）。

在 PostgreSQL 中，当你执行 DELETE 或 UPDATE 操作时，数据库并没有直接在物理磁盘上删除或覆盖旧数据。相反：

DELETE：只是将旧数据行（在 PG 中称为 Tuple，元组）标记为“已删除”（死元组，Dead Tuple）。
UPDATE：等同于先 DELETE 原来的行（标记为死元组），然后再 INSERT 一行新的数据。

VACUUM 的主要工作，就是去扫描这些表，找到那些对所有当前及未来事务都不可见的“死元组”，并将其占用的物理空间标记为“可用”，以便未来的 INSERT 或 UPDATE 可以复用这些空间。

二、为什么 PostgreSQL “必须”执行 VACUUM 操作？

PostgreSQL 必须执行 VACUUM，绝不仅仅是为了节省一点磁盘空间。如果不执行 VACUUM，数据库最终会面临性能崩溃甚至彻底罢工。具体原因有以下四个核心：

1. 回收空间，防止表膨胀（Table Bloat）

由于 MVCC 的机制，频繁的更新和删除会产生大量的“死元组”。

如果不执行 VACUUM：这些死元组会一直占用物理磁盘空间，导致表文件和索引文件越来越大（即“表膨胀”）。这不仅浪费磁盘空间，还会导致数据库在查询时需要扫描更多毫无用处的数据块，使查询速度呈现断崖式下降。
VACUUM 的作用：清理死元组，将空间释放给 Free Space Map (FSM)，供后续新数据使用，维持表大小的稳定。(注意：普通的 VACUUM 只会标记空间可复用，不会把空间还给操作系统；VACUUM FULL 才会重写表并把空间还给系统，但这会锁表)。

2. 防止事务 ID 回卷（Transaction ID Wraparound）—— 最致命的原因

这是 PostgreSQL 必须执行 VACUUM 的绝对理由，关系到数据库的生死存亡。

机制：PostgreSQL 使用一个 32 位的整数来记录事务 ID（XID），最大值约为 42 亿。PG 通过比较事务 ID 的大小来判断一行数据对当前事务是否可见（比如：XID 比我小的旧数据我能看见，XID 比我大的未来数据我看不见）。为了循环使用这 42 亿个 ID，PG 将其分为两半：21 亿属于“过去”，21 亿属于“未来”。
如果不执行 VACUUM：当数据库不断运行，消耗了超过 21 亿个事务 ID 后，如果不做处理，新的事务 ID 会“绕圈”回到过去。此时，数据库会错乱，认为所有以前的旧数据都变成了“未来的数据”，从而导致所有旧数据瞬间在数据库中不可见（相当于数据全部丢失）。
VACUUM 的作用：VACUUM 有一个特殊的操作叫 VACUUM FREEZE。它会扫描那些非常古老的行，将其事务 ID 替换为一个特殊的标记（Frozen XID）。带有这个标记的行，对所有事务永远可见。这样就“重置”了时间，防止了事务 ID 耗尽导致的灾难。如果不做清理，当 XID 接近枯竭时，PG 会为了保护数据直接强制停机并拒绝任何写入，直到你手动完成 VACUUM。

3. 更新统计信息（配合 ANALYZE）

机制：PostgreSQL 的查询优化器（Query Planner）在决定如何执行一条 SQL（是走全表扫描还是走索引）时，依赖于表数据的统计信息。
如果不执行 VACUUM：通常 VACUUM 和 ANALYZE 会一起执行（VACUUM ANALYZE）。如果长期不清理和分析，优化器拿到的就是过时的统计信息，从而做出极其愚蠢的查询计划，导致原本毫秒级的查询变成几分钟。

4. 维护可见性映射（Visibility Map, VM）

机制：PostgreSQL 维护了一个叫 VM 的数据结构，用来记录哪些数据页（Page）里只有活着的元组（即没有死元组）。
VACUUM 的作用：VACUUM 会更新这个 VM。这有两个巨大好处：
1. 加速后续的 VACUUM：下次 VACUUM 时可以直接跳过这些全是活数据的页，大大提高清理速度。
2. 支持 Index-Only Scans（仅索引扫描）：如果查询只涉及到索引里的列，且 VM 告诉数据库这个数据页全是可见的，数据库就可以直接从索引中返回结果，而不需要再去读取底层的数据表（Heap），极大提升查询性能。

总结

在 PostgreSQL 中，VACUUM 不是可有可无的优化手段，而是维持数据库健康运转的生命线。

幸运的是，现代版本的 PostgreSQL 默认开启了 Autovacuum（自动清理） 后台守护进程。它会根据表的变化频率（如死元组达到一定比例）自动在后台默默执行 VACUUM 操作。对于绝大多数现代 PG 部署来说，DBA 的主要任务是调整 Autovacuum 的参数使其运行得更快、更及时，而不是关闭它。关闭 Autovacuum 是一场注定会发生的灾难。

播面