在像'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

時間戳上的索引通常響應范圍查詢，即>，<，之間，<=等。但是，正如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

如果你玩，你可以看到使用索引實際上更慢。

Answer 2

使用索引意味着讀取索引並從表中讀取所選行。 需要權衡的是，僅僅讀取表格就可以更有效率。 DBMS用於選擇哪個更適合任何給定查詢的算法通常都很好（盡管不完美）。

很容易（並且可能）不使用索引是此查詢的更好選擇。

使用@ Clockwork-Muse和@univerio建議選擇性通常是一個好主意，盡管在這種情況下由於表大小可能無關緊要。 您還可以使用ORDER BY created_at來查看它是否會影響計划。

實驗（根據@FuzzyChef）可以幫助找到權衡點。 使用不同的表大小並更改其他變量以查看結果。