小编Jas*_*orn的帖子

我有一个由 Postgres 数据库支持的 Web API，性能通常非常好。我监控整个数据库和应用程序的性能。我的大部分查询（以及与此相关的 API 调用）都在不到 100 毫秒内完成，但偶尔会出现异常值。

就在今天，我收到一条警报，指出 API 调用耗时超过 5,000 毫秒，因此被看门狗终止。从挖掘日志开始，底层的 Postgres 查询花费了 13秒的时间来完成（一切都是异步的，所以即使 API 请求被终止，SQL 查询仍在继续）。

这是非常不典型的，即使当我手动运行有问题的查询时，我也无法重现这种糟糕的时间安排。它对我来说在 985 毫秒内完成（根据解释分析）。

我的问题

我不知道接下来还要看什么来尝试制定关于为什么会发生这种情况的理论。这种情况并不经常发生，每天只有成千上万次类似事件发生一次或两次，但它确实经常发生，令人讨厌。我错过了什么？我应该下一步做什么来调试它？我不是来自 DBA 背景，所以这可能是一个愚蠢的问题。

一些快速背景和我尝试过的

这一切都托管在 Amazon 的 RDS 上，在 m3.xlarge 上运行 Postgres 9.4，预配置 IOPS (2,000)。

我的一个表，我们称之为“详细信息”相当大，包含近 500 万行，并且以每天 25,000 条记录的速度增长。这个表永远不会更新或删除，只是插入和选择，但代表了我的应用程序的“核心”——几乎所有感兴趣的东西都是从这个表中读取的。

在这个特定情况下，我知道这个查询有一些参数（例如底部的日期和 id），因此它正在查看一个相当大的数据集。我已经开发了这个查询的一个大大改进的版本，它将这个特定场景从 985 毫秒减少到 20 毫秒。但是，我担心这里还有其他“在起作用”的东西，一个查询需要不到一秒的时间来运行我，在生产中时不时需要超过 13 秒。

桌子

嗯，有点……它包含更多的列，但我删除了任何不在查询中或没有索引的列。以下查询中使用的所有列或附加索引的所有列都已保留；

CREATE TABLE "public"."details" (
    "value" numeric,
    "created_at" timestamp(6) WITH TIME ZONE NOT NULL,
    "updated_at" timestamp(6) WITH TIME ZONE NOT NULL,
    "effective_date" timestamp(6) …