mysql-当查询“ where created_at>”时,索引是否起作用？

我使用的是Postgresql,需要进行类似“ WHERE created_at> ？”.我不确定索引是否可以在这种查询中使用.

我做了一个实验.在created_at列上添加索引后,我解释了以下两个查询.

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)

请注意,第一个使用“过滤器”,而第二个使用“索引容器”,根据Postgresql的文档,前者只是一个一对一的扫描,而后者则使用索引.

是否表示类似“ created_at> ‘将不会通过在’created_at’列上添加索引来固定？

更新资料

我正在使用Rails 4.0,并且根据控制台,索引是由创建的

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

解决方法:

时间戳索引通常响应范围查询,即>,<,之间,<=等.但是,正如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

如果您四处逛逛,则可以看到实际上使用索引的速度较慢.