索引大小比表本身大 20 倍，查询速度非常慢

Question

我要查询的表只有大约 3000 行和 3 列：

int/varchar(100)/varchar(100) 

但是查询它们需要大约 30 秒！

然后我看到表大小是 1331MB 但索引大小是 25GB！

该表只有一个索引，即 pkey。

VACCUM FULL 每 24 小时运行一次，无论如何桌子应该是静态的

我的问题是为什么索引这么大（我想这就是查询如此缓慢的原因），我该怎么做才能解决这个问题？

希望你有任何想法，因为我没有，我在谷歌上也没有找到任何东西。

编辑：Postgres 版本是 8.1.18

Answer 1

9.0 之前 VACUUM FULL

你是PostgreSQL的8.4或以上，其中VACUUM FULL趋于膨胀指标。有关详细信息，请参阅此 wiki 页面。

不要VACUUM FULL作为定期维护任务运行。这是不必要的和低效的。这在当前版本中仍然如此，只是在 9.0 及更高版本上没有那么糟糕。如果您觉得需要VACUUM FULL定期运行，那么您可能没有将 autovacuum 设置得足够远，并且会遇到表膨胀问题。事实上，除非你已经改变了FILLFACTOR从它的默认表中100一个VACUUM FULL相当适得其反; 它将压缩表中的所有可用空间，因此以下UPDATEs 将不得不扩展表。

表扩展目前是 PostgreSQL 中性能较差的操作之一，因为它们由单个全局锁控制。因此，如果您有大小波动的表，您真的希望避免不断压缩和截断它们只是为了再次扩展它们。

在一些不寻常的工作负载上，值得运行一个 Period CLUSTER，它根据索引对表进行排序并有效地对其进行REINDEX排序。如果你UPDATE在桌子上做很多s 应该设置一个较低FILLFACTOR的效率。

如果此表被定期清空并重新填充，您通常应该使用TRUNCATE 后跟COPY来填充它。如果它很大，请先删除索引，COPY然后再重新创建它们，以生成更紧凑、更快的索引并加快数据加载速度。

对于一次性缓解，CLUSTER表格或REINDEX它。

8.1？！？！

编辑后添加版本：神圣的bleepazoids，蝙蝠侠。8.1.18？忘记我说的 autovacuum，8.1 中的 autovacuum 太无效了。尽快升级到健全的版本。从 2010 年 12 月开始，您甚至还没有使用 8.1、8.1.23 的当前版本。8.1.18 已于 2009 年 9 月发布！您需要开始升级计划……嗯，最好在大约两年前。阅读8.1 和当前版本之间每个 .0 版本的发行说明，重点关注升级说明和兼容性说明。然后计划并执行升级。如果你不觉得自己管理，有人会帮助你 （我为其中之一工作）但老实说，发行说明和文档足以让大多数人自己进行升级而不会造成不必要的痛苦。

从 8.1 迁移到 8.3 或更新版本将是您最大的痛点，因为 PostgreSQL 8.3 放弃了大量潜在错误 SQL 所依赖的大量隐式强制转换。您需要在较新版本上仔细测试您的应用程序。其他需要注意的变化是：

• 删除隐式FROM并在更高版本中删除它的向后兼容性参数；
• 新版本中的 UTF-8 验证改进可能导致旧转储无法加载，直到数据得到更正；
• standard_conforming_strings默认更改为；
• 的变化bytea_output来hex