21.1.1. 恢复磁盘空间

在正常的 PostgreSQL 操作里， 对一行的UPDATE或DELETE并未立即删除旧版本的数据行。 这个方法对于获取多版本并行控制的好处是必要的（参阅 Chapter 12）： 如果一个行的版本仍有可能被其它事务看到，那么你就不能删除它。 但到了最后，不会有任何事务对过期的或者已经删除的元组感兴趣。 而它占据的空间必须为那些新的元组使用而回收， 以避免对磁盘空间增长的无休止的需求。这件事是通过运行 VACUUM 实现的。

很明显，那些经常更新或者删除元组的表需要比那些较少更新的表清理的更频繁一些。 所以，设置一个周期性的 cron 任务 VACUUM 那些选定的表，而忽略那些已经知道变化比较少的表． 这个方法只是在你拥有大量更新频繁的表和大量很少更新的表的时候有意义 — 清理一个小表的额外开销根本不值得担心．

VACUUM 命令有两个变种。第一种形式，叫做"懒汉 vacuum"或者只是 VACUUM， 在表和索引中标记过期的数据为将来使用；它并不试图立即恢复这些过期数据使用的空间。 因此，表文件不会缩小，并且任何文件中没有使用的空间都不会返回给操作系统。 这个变种的 VACUUM 可以和通常的数据库操作并发执行。

第二种形式是 VACUUM FULL 命令。 这个形式使用一种更加激进的算法来恢复过期的的行版本占据的空间。 任何 VACUUM FULL 释放的空间都立即返回给操作系统。 但是，这个形式的 VACUUM 命令在进行 VACUUM FULL 一个表的时候在其上要求一个排他锁。 因此，经常使用 VACUUM FULL 会对并发数据库查询有着非常糟糕的影响。

标准形式的 VACUUM 最适合用于维护相当程度的磁盘用量的稳定状态。 如果你需要把磁盘空间归还给操作系统，那么你可以使用 VACUUM FULL — 不过如果释放的磁盘空间又会很快再次被分配又怎样？ 如果维护更新频繁的表，那么中等频率的多次标准 VACUUM 运行方法比很低频率的 VACUUM FULL 更好。

对于大多数节点而言，我们推荐的习惯是在一天中的低使用的时段安排一次整个数据库的 VACUUM， 必要时外加对更新频繁的表的更经常的清理。 （有些环境下，对那些更新非常频繁的表可能会每几分钟就 VACUUM 一次。） 如果你的集群中有多个数据库，别忘记对每个库进行清理；vacuumdb 脚本可能会帮你的忙。

如果你知道自己刚删除掉一个表中大部分的行，那么我们建议使用VACUUM FULL， 这样该表的稳定态尺寸可以因为VACUUM FULL更富侵略性的方法而显著减小。 日常的磁盘空间清理，请使用 VACUUM，而不是 VACUUM FULL。

如果你有一个表，它的内容经常被完全删除，那么可以考虑用 TRUNCATE，而不是后面跟着 VACUUM 的 DELETE。 TRUNCATE 立即删除整个表的内容， 而不要求随后的 VACUUM 或者VACUUM FULL 来恢复现在没有用的磁盘空间。

21.1.2. 更新规划器统计

PostgreSQL 的查询规划器依赖一些有关表内容的统计信息用以为查询生成好的规划。 这些统计是通过ANALYZE 命令获得的，你可以直接调用这条命令， 也可以把它当做 VACUUM 里的一个可选步骤来调用。 拥有合理准确的统计是非常重要的，否则，选择了恶劣的规划很可能降低数据库的性能。

和为了回收空间做清理一样，经常更新统计信息也是对更新频繁的表更有用。 不过，即使是更新非常频繁的表，如果它的数据的统计分布并不经常改变，那么也不需要更新统计信息。 一条简单的拇指定律就是想想表中字段的最大很最小值改变的幅度。 比如，一个包含行更新时间的 timestamp 字段将是随着行的追加和更新稳定增长最大值的； 这样的字段可能需要比那些包含访问网站的 URL 的字段更频繁一些更新统计信息。 那些 URL 字段可能改变得一样频繁，但是其数值的统计分布的改变相对要缓慢得多。

我们可以在特定的表，甚至是表中特定的字段上运行 ANALYZE， 所以如果你的应用有需求的话，我们是可以对某些信息更新得比其它信息更频繁的。 不过，在实际中，这种做法的有用性是值得怀疑的。 从 PostgreSQL 7.2 开始， ANALYZE 是一项相当快的操作，即时在大表上也很快， 因为它使用了统计学上的随机采样的方法进行行采样， 而不是把每一行都读取进来。因此，每隔一段时间对整个数据库运行一便这条命令可能更简单。

我们对大多数节点都建议在每天的低使用时段安排一次数据库范围的 ANALYZE： 这个任务可以有效地和每天的 VACUUM 组合在一起。 不过，这对那些表统计信息改变相对缓慢的节点可能会过于夸张， 而且少一些的 ANALYZE 也足够了。

21.1.3. 避免事务 ID 重叠造成的问题

PostgreSQL 的 MVCC 事务语意依赖于比较事务 ID(XID)的数值： 一条带有大于当前事务的 XID 的插入 XID 的行版本是"属于未来的"， 并且不应为当前事务可见。但是因为事务 ID 的大小有限（在我们写这些的时候是 32 位），如果一次集群如果运行的时间很长（大于 4 千兆次事务）， 那么它就要受到事务 ID 重叠的折磨∶XID 计数器回到零位， 然后突然间所有以前的事务就变成看上去是在将来的 --- 这意味着它们的输出将变得可见。 简而言之，可怕的数据丢失，（实际上数据仍然在那里，但是如果你无法获取数据，这么说也只是幸灾乐祸。）

在 PostgreSQL 7.2 之前， 防御 XID 重叠的唯一办法就是至少每4千兆事务就重新做一次initdb。 这种做法对高流量的节点而言当然不是令人满意的做法，所以我们设计了更好的方法。 新的方法允许某个服务器仍然保持运行状态，不需要 initdb 或者任何类型的重启。 代价就是下面这样的维护要求： 数据库中的每个表都必须在每十亿次事务中至少清理一次 ．

从实际角度出发，这个要求不算一个很繁重的要求， 但是因为如果我们没能满足这个要求的后果是全部数据的丢失（而不仅仅是磁盘空间的浪费或者性能的下降）， 我们制作了一些特殊的东西来帮助数据库管理员跟踪自上次VACUUM 以来的时间。本节剩余的部分给出这些细节。

XID 比较的新方法剥离出两个特殊的 XID，数字 1 和 2 （BootstrapXID 和 FrozenXID）。 这两个 XID 总是被认为表任何普通的 XID 旧。普通的 XID（那些大于 2 的）使用模-2³¹运算进行比较。 这就意味着对于每个普通的 XID，总是有二十亿个 XID 是"更旧"以及二十亿个 XID"更新"； 表达这个意思的另外一个方法是普通的 XID 空间是没有终点的环。 因此，一旦一条元组带着特定的普通 XID 创建出来，那么该元组 将在以后的二十亿次事务中表现得是"在过去"，而不管我们说的是哪个普通 XID。 如果该元组在超过二十亿次事务之后仍然存在， 那么它就会突然变成在将来的元组。为了避免数据丢失，老的元组必须在到达二十亿次事务的年龄之前的某个时候赋予 XID FrozenXID。 一旦它被赋予了这个特殊的 XID，那么它们在所有普通事务面前表现为 "在过去"，而不管事务 ID 是否重叠， 因此这样的元组直到删除之前都会完好，不管要保存多长时间．这个 XID 的重新赋值是VACUUM 控制的．

VACUUM 的正常策略是给任何其普通 XID 有超过十亿次已过去事务行版本重新赋值为 FrozenXID。 这个策略保留了原来的插入 XID 直到该数值不再令人感兴趣为止。 （实际上，大多数行版本将可能在还没有"冻结"之前就完成生存和消亡了）。 在这个策略下，任何表在两次 VACUUM 运行之间的最大的安全间隔是十亿次事务： 如果你等的时间更长，那么最后就可能就会有一条不够老的行版本在重新赋值时变成比二十亿次事务更老， 并因此重叠到了未来 — 也就是说，你失去它了。（当然，它在另外二十亿次事务之后会重新出现，不过那样也无济于事。）

因为上面的原因，我们需要周期性地运行 VACUUM， 所以很难有哪个表会到十亿次事务还没有清理过。但是，为了帮助管理员确保满足了这个要求， VACUUM 在系统表pg_database 里存储了事务 ID 统计。 尤其是一个数据库的 pg_database 行中的 datfrozenxid 字段在任何数据库范围的 VACUUM 操作（也就是没有声明任何表的VACUUM）之后将会被更新。 这个字段里存储的数值是该 VACUUM 命令使用的冻结终止的 XID。 系统保证在该数据库中所有比这个终止 XID 老的普通 XID 都被 FrozenXID 代替。 检查这个信息的一个便利的方法是执行下面的查询

SELECT datname, age(datfrozenxid) FROM pg_database;

age 字段用于测量从终止 XID 到当前事务的 XID 的数目。

使用了这种标准的冻结策略，对一个刚清理过的数据库而言， age 字段将从十亿处开始。当age到达二十亿次的时候， 数据库必须再次清理以避免事务标识重叠造成的问题。 我们建议的策略是至少每半个十亿次（5亿次）事务 VACUUM 一次数据库， 这样就可以保证足够的安全边界范围．为了帮助满足这条规则， 如果有任何 pg_database 记录显示出超过15亿次事务的 age， 那么每次数据库范围的VACUUM 都会自动发出一条警告，比如：

play=# VACUUM;
WARNING:  Some databases have not been vacuumed in 1613770184 transactions.
        Better vacuum them within 533713463 transactions,
        or you may have a wraparound failure.
VACUUM

带着 FREEZE 选项的 VACUUM 使用了更大胆的冻结策略： 如果行版本已经老得被所有打开的事务看做是良好的， 那么就都冻结．特别是如果在一个空闲的数据库上运行 VACUUM FREEZE，那么就保证该数据库中所有的行版本都被冻结。 因此，只要该数据库没有其它的变化，那么它就不需要后续的清理以避免事务 ID 重叠问题。 这个技巧被 initdb 用于准备 template0数据库。 我们也应该用这个方法对所有在 pg_database表里标记着 datallowconn = false的数据库进行初始化， 因为我们还没有任何便利的方法 VACUUM 一个你无法联接的数据库。 请注意，VACUUM 将忽略那些pg_database 记录里有 datallowconn = false 条件的有关未清理数据库的自动警告信息。 以避免给出关于这些数据库的虚假的警告信息； 因此，确保这样的数据库的正常冻结是你的责任。