Postgres TIMESTAMP 索引和查询性能答案

【问题标题】：Postgres TIMESTAMP index and query performancePostgres TIMESTAMP 索引和查询性能
【发布时间】：2021-02-25 00:54:40
【问题描述】：

我有这张桌子：

CREATE TABLE IF NOT EXISTS CHANGE_REQUESTS (
    ID             UUID PRIMARY KEY,
    FIELD_ID             INTEGER NOT NULL,
    LAST_CHANGE_DATE    TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL
);

而且我总是会在上面运行完全相同的查询：

select * from change_requests where last_change_date > now() - INTERVAL '10 min';

表的大小平均在 750k 到 100 万行之间。

我的问题是如何确保查询总是非常快？我正在考虑在last_change_date 上添加一个索引，但我不确定这是否会起作用。我试过了（现在表中只有 1 行）并得到了这个解释：

create index change_requests__dt_index
    on change_requests (last_change_date);

Seq Scan on change_requests  (cost=0.00..1.02 rows=1 width=28)
  Filter: (last_change_date > (now() - '00:10:00'::interval))

所以它似乎根本没有使用索引。

这个索引真的有用吗？如果没有，我还能做什么？谢谢！

【问题讨论】：

只有一行并不多，再试一次（很多）更多行。一般来说，你的索引很好，会支持查询。您可以尝试通过在 (last_change_date, id, field_id) 上放置索引来改进它。然后整个查询可以由索引单独回答。
是的，我认为 1 行不会告诉我它实际上有多快，但它至少不会提到它正在使用索引吗？至于将索引放在（last_change_date，id，field_id）上，你能解释一下那会做什么吗？除了 last_change_date 之外，我从来没有真正搜索过任何列，那么将这些其他字段添加到索引中会做什么？
如果它不决定使用索引，因为它只是一行没有意义，不，它不会说它使用索引。并且您想要输出中的其他列。这就是为什么包含它们的索引可能是有益的。它可以直接用于获取这些列，而无需先从表中读取它们。
有趣，好的。我不知道在决定是否使用索引时会考虑行数，感谢您提供的信息。实际上，我一次只生成了 250k 的 100 万行，最后当我在表中达到 100 万行时，它更改了解释以开始使用索引。非常感谢您的帮助！

标签： postgresql indexing timestamp

【解决方案1】：

您的索引非常适合这项任务。您会在执行计划中看到顺序扫描，因为表中没有实际数量的测试数据，而且对于非常小的表，使用索引的开销不值得付出努力（您必须处理更多 8kB数据库块）。

始终使用真实数量的数据进行测试。这样你以后就不会痛苦了。

【讨论】：