mysql - 像 'where created_at > ?' 这样的查询时索引是否工作

Question

我正在使用 Postgresql，需要进行类似“WHERE created_at > ?”的查询。我不确定索引是否适用于此类查询。

我做过一个实验。在 created_at 列上添加索引后，我解释了以下 2 个查询。

1)

EXPLAIN SELECT * FROM categories WHERE created_at > '2014-05-03 21:34:27.427505';

结果是

QUERY PLAN
------------------------------------------------------------------------------------
 Seq Scan on categories  (cost=0.00..11.75 rows=47 width=528)
   Filter: (created_at > '2014-05-03 21:34:27.427505'::timestamp without time zone)

2)

EXPLAIN SELECT * FROM categories WHERE created_at = '2014-05-03 21:34:27.427505';

结果是

                                            QUERY PLAN
---------------------------------------------------------------------------------------------------
 Index Scan using index_categories_on_created_at on categories  (cost=0.14..8.16 rows=1 width=528)
   Index Cond: (created_at = '2014-05-03 21:34:27.427505'::timestamp without time zone)

请注意，第一个使用的是“Filter”，而第二个使用的是“Index Cond”，根据 Postgresql 的文档，前者只是逐一扫描，而后者使用的是索引。

它是否表示像“created_at >”这样的查询？不会通过在“created_at”列上添加索引来固定？

---

更新

我正在使用 Rails 4.0，根据控制台，索引是由

CREATE  INDEX  "index_categories_on_created_at" ON "categories"  ("created_at")

Answer 1

时间戳上的索引通常响应范围查询，即 >、<、between、<= 等。但是，正如 univero 指出的那样，选择性和成本估算起着重要作用。

PostgreSQL 只有在认为使用索引比不使用索引更快时才会使用索引(就此而言，如果有多个索引可用，它会尝试选择最快的索引来使用)。它期望从 > 查询返回的那 47 行在表中有多少？如果答案是“表的 10%”，那么 Postgres 不会为索引操心。就此而言，查询规划器很少使用索引来扫描非常小的表，因为如果您的整个表适合 3 个数据页，则扫描整个表会更快。

如果你愿意，你可以很容易地玩这个。

1) 使用 EXPLAIN ANALYZE 而不仅仅是 EXPLAIN，这样您就可以比较查询规划器预期的结果与实际得到的结果。

2) 使用以下任一语句关闭和打开索引和表扫描:

SET enable_seqscan = false; --turns off table scans
SET enable_indexscan = false; -- turns of index scans
SET enable_bitmapscan = false; -- turns off bitmap index scans

如果您尝试一下，您会发现在哪些地方使用索引实际上速度较慢。