【问题标题】:Why does this query not use the index?为什么这个查询不使用索引?
【发布时间】:2015-06-11 09:12:37
【问题描述】:

我在以下查询中遇到了 Postgres 优化器的奇怪行为:

select count(product0_.id) as col_0_0_ from Product product0_ 
 where product0_.active=true 
 and (product0_.aggregatorId is null 
 or product0_.aggregatorId in ($1 , $2 , $3))

Product 大约有 54 列,active 是具有 btree 索引的布尔值,aggregatorId 是 'varchar(15)` 并具有 btree 索引。

在上面的查询中,没有使用“aggregatorId”的索引:

Aggregate  (cost=169995.75..169995.76 rows=1 width=32) (actual time=3904.726..3904.727 rows=1 loops=1)
  ->  Seq Scan on product product0_  (cost=0.00..165510.39 rows=1794146 width=32) (actual time=0.055..2407.195 rows=1851827 loops=1)
        Filter: (active AND ((aggregatorid IS NULL) OR ((aggregatorid)::text = ANY ('{5109037,5001015,70601}'::text[]))))
        Rows Removed by Filter: 542146
Total runtime: 3904.925 ms

但是如果我们通过省略对该列的空检查来减少查询,则索引会被使用:

Aggregate  (cost=17600.93..17600.94 rows=1 width=32) (actual time=614.933..614.935 rows=1 loops=1)
  ->  Index Scan using idx_prod_aggr on product product0_  (cost=0.43..17487.56 rows=45347 width=32) (actual time=19.284..594.509 rows=12099 loops=1)
      Index Cond: ((aggregatorid)::text = ANY ('{5109037,5001015,70601}'::text[]))
      Filter: active
    Rows Removed by Filter: 49130
Total runtime: 150.255 ms

据我所知,btree 索引可以处理空检查,所以我不明白为什么索引不用于完整查询。产品表包含大约 230 万个条目,因此速度不是很快。

编辑: 指标很标准:

CREATE INDEX idx_prod_aggr
  ON product
  USING btree
  (aggregatorid COLLATE pg_catalog."default");

【问题讨论】:

  • 你能告诉我们explain analyze的输出吗?
  • @a_horse_with_no_name 我已经添加了解释分析结果。
  • aggregatorId 中的空行是否可能太多?
  • @DraganBozanovic 太多是什么意思?空值占多数(约 1.8m)。
  • 请看下面我的回答。

标签: sql postgresql


【解决方案1】:

由于您在 where 子句中使用的列有许多相同的值(根据您的数字,占所有表行的 78%),数据库将得出结论,使用全表扫描比浪费额外的成本更便宜是时候阅读索引了。

大多数数据库供应商的经验法则是,如果不能将搜索范围缩小到所有表记录的 5% 左右,则可能不会使用索引。

【讨论】:

  • 有没有办法告诉 Postgres 在给定的情况下使用不同的行为?因为在这里恕我直言,使用索引也会更快。
  • @UweAllner:您可以在运行查询之前使用set enable_seqscan=off 来关闭 seq 扫描的使用 - 但如果对这么多行的索引查找实际上会更便宜,我会感到惊讶/更快
  • @a_horse_with_no_name 是的,你是对的,禁用 seqscan 后需要 10 秒...
【解决方案2】:

您的问题看起来很有趣,所以我重现了您的场景 - postgres 9.1,具有 1M 行的表,一个布尔列,一个 varchar 列,均已编入索引,一半的表具有 NULL 名称。

当 varchar 列被编入索引时,我有相同的解释分析输出。但是,带有索引的 postgres 在 NULL 条件和 IN 条件上使用位图扫描,然后将它们与 OR 条件合并。

然后他在布尔条件下使用 seq 扫描(因为索引是分开的)

explain analyze
select * from A where active is true and ((name is null) OR (name in ('1','2','3')  ));

查看输出:

"Bitmap Heap Scan on a  (cost=17.34..21.35 rows=1 width=18) (actual time=0.048..0.048 rows=0 loops=1)"
"  Recheck Cond: ((name IS NULL) OR ((name)::text = ANY ('{1,2,3}'::text[])))"
"  Filter: (active IS TRUE)"
"  ->  BitmapOr  (cost=17.34..17.34 rows=1 width=0) (actual time=0.047..0.047 rows=0 loops=1)"
"        ->  Bitmap Index Scan on idx_prod_aggr  (cost=0.00..4.41 rows=1 width=0) (actual time=0.010..0.010 rows=0 loops=1)"
"              Index Cond: (name IS NULL)"
"        ->  Bitmap Index Scan on idx_prod_aggr  (cost=0.00..12.93 rows=1 width=0) (actual time=0.036..0.036 rows=0 loops=1)"
"              Index Cond: ((name)::text = ANY ('{1,2,3}'::text[]))"
"Total runtime: 0.077 ms"

这让我觉得你遗漏了一些细节,如果有,请将它们添加到你的问题中。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-10-05
    • 1970-01-01
    • 1970-01-01
    • 2011-08-24
    • 2021-12-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多