2016-12-16 90 views
2

我有以下查询:上Postgres SQL查询忽略索引?

SELECT a.id, a.col2, b.id, b.col2, c.id, c.col2 
FROM a 
    JOIN b on b.fk_a_id = a.id 
    JOIN c on c.fk_a_id = a.id 
    INNER JOIN d on d.fk_c_id = c.id 
WHERE a.owner_id NOT IN (1, 3, 100, 41) 
GROUP BY a.id, b.id, c.id 
ORDER BY a.created_date desc 
LIMIT __ OFFSET __ 

指标: a.id,a.owner_id,b.id,c.id

然而,没有我的指标正在此查询使用。我有另一个类似的查询,其中有一个额外的表连接,正如我所期望的那样使用索引关于为什么这个查询没有使用索引的任何想法?

编辑包括解释:

"Limit (cost=7.88..7.89 rows=4 width=243) (actual time=175.824..175.825 rows=10 loops=1)" 
" -> Sort (cost=7.88..7.89 rows=4 width=243) (actual time=175.822..175.822 rows=10 loops=1)" 
"  Sort Key: a.created_date DESC" 
"  Sort Method: quicksort Memory: 27kB" 
"  -> HashAggregate (cost=7.78..7.84 rows=4 width=243) (actual time=175.771..175.778 rows=10 loops=1)" 
"    Group Key: a.id, b.id, c.id" 
"    -> Hash Join (cost=5.12..7.75 rows=4 width=243) (actual time=0.072..0.099 rows=20 loops=1)" 
"     Hash Cond: (a.id = b.fk_a_id)" 
"     -> Hash Join (cost=2.85..5.43 rows=4 width=163) (actual time=0.041..0.063 rows=20 loops=1)" 
"       Hash Cond: (a.id = d.fk_a_id)" 
"       -> Seq Scan on table a (cost=0.00..2.44 rows=27 width=126) (actual time=0.008..0.025 rows=28 loops=1)" 
"        Filter: (owner_id <> ALL ('{1,3,100,41}'::bigint[]))" 
"        Rows Removed by Filter: 1" 
"       -> Hash (cost=2.76..2.76 rows=7 width=53) (actual time=0.027..0.027 rows=3 loops=1)" 
"        Buckets: 1024 Batches: 1 Memory Usage: 9kB" 
"        -> Hash Join (cost=1.16..2.76 rows=7 width=53) (actual time=0.019..0.023 rows=3 loops=1)" 
"          Hash Cond: (c.id = d.fk_c_id)" 
"          -> Seq Scan on table c (cost=0.00..1.39 rows=39 width=45) (actual time=0.002..0.004 rows=39 loops=1)" 
"          -> Hash (cost=1.07..1.07 rows=7 width=8) (actual time=0.007..0.007 rows=3 loops=1)" 
"           Buckets: 1024 Batches: 1 Memory Usage: 9kB" 
"           -> Seq Scan on table d (cost=0.00..1.07 rows=7 width=8) (actual time=0.003..0.004 rows=3 loops=1)" 
"     -> Hash (cost=2.12..2.12 rows=12 width=88) (actual time=0.022..0.022 rows=12 loops=1)" 
"       Buckets: 1024 Batches: 1 Memory Usage: 9kB" 
"       -> Seq Scan on table b (cost=0.00..2.12 rows=12 width=88) (actual time=0.005..0.013 rows=12 loops=1)" 
"Planning time: 210.946 ms" 
"Execution time: 175.987 ms" 
+0

'EXPLAIN'查询并发布结果。 – Stavr00

+2

哦,我知道为什么! Postgres优化器认为全表扫描是执行查询的最高性能方式。为什么它认为,我不知道。优化器可以访问大量我没有的信息。 。 。表格大小,估计分布,涉及的确切数据类型等等。 –

+0

我刚刚编辑,包括EXPLAIN – Dayna

回答

0

有ONY上表A中的标准:WHERE a.owner_id NOT IN (1, 3, 100, 41)。对我来说,听起来像“选择除了几个以外的所有记录”。通过索引读取所有记录并且仍然以大部分记录结束将是很多工作。简单地阅读表格并即时忽略一些记录的速度会更快。

然后,对于那些许多许多A记录,我们可能会匹配很多很多的B,C和D记录。同样,我们最好不要读索引加上大部分表数据,而只是把数据放入桶中(散列连接)。这似乎最快。

因此,优化器选择不为查询使用索引似乎是一个好主意。实践证明,它是做好:-)

我看到索引,以加快这唯一的办法将覆盖索引,即包含所有需要的列的索引:

  • 一个(owner_id,ID, CREATED_DATE,COL2)
  • b(fk_a_id,ID,COL2)
  • C(fk_a_id,ID,COL2)
  • d(fk_c_id)

然后我们止跌不必阅读索引加上表格,而是仅索引。

顺便说一句:因为你不从D中选择任何东西,你要么检查是否存在,那么你应该使用EXISTSIN而不是加入以提高可读性。或者你不知道;那么你可以从你的查询中完全消除它。

+0

我对此很新。我在我正在测试的本地数据库上执行VACUUM,并且索引正在使用中? – Dayna

0

索引用于(快速)在“多行”中查找“少数几行”。这不是一个神奇的银弹,让一切变得更快。

表中没有足够的行来使索引查找有效。而且你几乎获得了所有这些,而不仅仅是一小部分。

如果你看看这个计划,你会发现实际的数据检索永远不会超过0.1毫秒。 (这是毫秒秒的十分之一)。对于表cd的Seq扫描仅需要0.004ms - 没有索引只会加速4行。

这样做通过索引与随机I/O为20或30行肯定会更慢。根据表中列的数量,即使“最大”表的39行可能存储在一个块中 - 这意味着要读取所有行,数据库只需要在使用Seq时执行单个I/O操作扫描。

计划的最慢的部分是HashAggregate读取数据的,所以不使用索引的选择似乎是正确的。

那是什么样的硬件?合计20行的175毫秒似乎非常慢 - 计划时间为210毫秒。对于这样一个简单的陈述,计划时间应该更像1ms。