大更新后，对单个 PostgreSQL 表的查找突然变得极其缓慢

如何解决大更新后，对单个 PostgreSQL 表的查找突然变得极其缓慢

我有一个 messages 表，里面有几百万条记录。我的 Rails 应用程序在大多数页面上都包含一个查询，用于计算向用户显示的未读 messages 的数量。此查询 - 以及 messages 表的所有查询 - 未发生变化，并且一直工作到昨天为止。

昨天，我创建了一个新的 messages 列并运行 update_all 来更新我的几百万个 messages 记录中的每一个的新列。很简单，我之前已经做过很多次了，尽管记录的数量较少。

但是，现在对 COUNT 或 SELECT messages 的每个查询都需要 30 多秒才能返回。在迁移和 update_all 之前，执行 COUNT 或 SELECT 只需要 100 毫秒左右。

我尝试了很多方法，但查询仍然非常缓慢。我试过REINDEX messages，也试过VACCUM messages，但都没有太大帮助。

其余的数据库表仍然照常工作，但 messages 表的这个问题使一切都在爬行中运行。有没有人知道为什么会发生这种情况，我还能尝试解决什么问题？

解决方法

我尝试过 REINDEX 条消息，也尝试过 VACCUM messages，但都没有显着帮助。

您错过了重要的 ANALYZE。可能采用 VACUUM ANALYZE 的形式。 （不过，通常 autovacuum 应该处理这个问题！）

更新所有行会在物理关系中创建尽可能多的死元组。为了释放空间，这可能是一个难得的机会

VACUUM FULL ANALYZE messages;

对表进行排他锁！而且由于您经常每个用户运行计数，您不妨使用 CLUSTER:

CLUSTER messages USING that_index_sorting_by_user_id_and_the_read_flag

对于每个用户的快速计数，无论哪种方式，适当的（多列）索引都是关键。取决于未公开的架构和查询。

艾尔说，您不应该看到性能下降如此显着。也许你耗尽了资源。比如，只是没有足够的内存来缓存更大的索引。