为什么 VACUUM FULL 后 PostgreSQL 性能没有恢复到最大值？答案

【问题标题】：Why doesn't PostgreSQL performance get back to its maximum after a VACUUM FULL?为什么 VACUUM FULL 后 PostgreSQL 性能没有恢复到最大值？
【发布时间】：2010-06-30 00:19:33
【问题描述】：

我有一张包含几百万元组的表。

我在其中的大多数中执行更新。

第一次更新大约需要一分钟。第二个，需要两分钟。第三次更新需要四分钟。

之后，我执行 VACUUM FULL。

然后，我再次执行更新，需要两分钟。

如果我转储数据库并重新创建它，第一次更新将需要一分钟。

为什么 VACUUM FULL 后 PostgreSQL 性能没有恢复到最大值？

【问题讨论】：

是什么让您认为 VACUUM FULL 可以解决您的问题？
我不确定，我只知道连续更新会降低性能。抽真空后，它会变得更好。但是，我只有删除/重新创建数据库才能获得初始速度

标签： postgresql performance

【解决方案1】：

VACUUM FULL 不会压缩索引。事实上，在执行 VACUUM FULL 之后，索引可能会变得更糟。在 VACUUM FULL 之后，您应该重新索引表。

但是，VACUUM FULL+REINDEX 很慢。您可以使用 CLUSTER 命令实现与压缩表和索引相同的效果，这只需一小部分时间。它还有一个额外的好处，它会根据您选择的 CLUSTER 索引对您的表进行排序。这可以提高查询性能。 CLUSTER over VACUUM FULL+REINDEX 的缺点是它在运行时需要大约两倍的磁盘空间。此外，如果您运行的版本早于 8.3，请务必小心使用此命令。它不是 MVCC 安全的，您可能会丢失数据。

另外，您可以执行无操作的 ALTER TABLE ... ALTER COLUMN 语句来消除表和索引膨胀，这是最快的解决方案。

最后，任何 VACUUM FULL 问题还应该说明您为什么需要这样做？这几乎总是由不正确的吸尘造成的。您应该运行 autovacuum 并对其进行适当调整，这样您就不必运行 VACUUM FULL。

【讨论】：

索引总是在真空满后重建

【解决方案2】：

元组的顺序可能不同，这会导致不同的查询计划。如果您想要固定顺序，请使用 CLUSTER。也降低 FILLFACTOR 并打开 auto_vacuum。你也分析过吗？

使用 EXPLAIN 查看查询是如何执行的。

【讨论】：

我更新了所有元组，有一些标记被标记为对它们进行分类。花费的时间在此更新中。当我重新运行更新时，速度变慢了
我发现了你上周回答的这个问题，它澄清了我的想法stackoverflow.com/questions/3100072/…
在 VACUUM FULL 之后运行 REINDEX TABLE 也是一个好主意。
另外，由于这是一个更新活动，在真空满后您将没有可用的空白页面，从而迫使系统分配更多空间。通常，如果活动仍然很高，并且您的空闲页面确实超过了可用空间图的大小，则常规清理比清理满对性能的影响更大。