gpt4 book ai didi

sql - 为什么这个 LEFT JOIN 运行缓慢?

转载 作者:行者123 更新时间:2023-11-29 14:22:34 25 4
gpt4 key购买 nike

PostgreSQL 查询的 LEFT JOIN 部分运行得相当慢,我不明白为什么。

完整查询:

SELECT t.id FROM tests t
LEFT JOIN tests c ON c.parent_id IN (t.id, t.parent_id)
INNER JOIN responses r ON (
r.test_id IN (t.id, t.parent_id, c.id)
) WHERE r.user_id = 333

tests.idtests.parent_id上有索引。

测试包含 28876 行(其中,有 1282 行 WHERE parent_id IS NOT NULL)。

查询的 LEFT JOIN 部分产生了 32098 行,大约需要 700 毫秒

SELECT t.id FROM tests t
LEFT JOIN tests c ON c.parent_id IN (t.id, t.parent_id)

查询的其余部分花费的时间可以忽略不计。

关于为什么它可能很慢,或者有更好的方法来实现同样的事情,有什么想法吗?

谢谢!


选择版本()

PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit

解释分析

(注意:这使用了真实的表名,usability_tests,我在前面的示例中将其简化为 tests。)

Nested Loop  (cost=5.18..158692.45 rows=80 width=4) (actual time=107.873..5718.295 rows=103 loops=1)
Join Filter: ((r.usability_test_id = t.id) OR (r.usability_test_id = t.parent_id) OR (r.usability_test_id = c.id))
-> Nested Loop Left Join (cost=0.56..136015.63 rows=28876 width=12) (actual time=0.091..486.496 rows=32098 loops=1)
Join Filter: ((c.parent_id = t.id) OR (c.parent_id = t.parent_id))
-> Seq Scan on usability_tests t (cost=0.00..1455.76 rows=28876 width=8) (actual time=0.042..39.558 rows=28876 loops=1)
-> Bitmap Heap Scan on usability_tests c (cost=0.56..4.60 rows=4 width=8) (actual time=0.010..0.011 rows=0 loops=28876)
Recheck Cond: ((parent_id = t.id) OR (parent_id = t.parent_id))
-> BitmapOr (cost=0.56..0.56 rows=4 width=0) (actual time=0.008..0.008 rows=0 loops=28876)
-> Bitmap Index Scan on index_usability_tests_on_parent_id (cost=0.00..0.28 rows=2 width=0) (actual time=0.003..0.003 rows=0 loops=28876)
Index Cond: (parent_id = t.id)
-> Bitmap Index Scan on index_usability_tests_on_parent_id (cost=0.00..0.28 rows=2 width=0) (actual time=0.001..0.001 rows=0 loops=28876)
Index Cond: (parent_id = t.parent_id)
-> Materialize (cost=4.62..153.63 rows=39 width=4) (actual time=0.001..0.076 rows=70 loops=32098)
-> Bitmap Heap Scan on responses r (cost=4.62..153.44 rows=39 width=4) (actual time=0.053..0.187 rows=70 loops=1)
Recheck Cond: (user_id = 3649)
-> Bitmap Index Scan on index_responses_on_user_id (cost=0.00..4.61 rows=39 width=0) (actual time=0.040..0.040 rows=70 loops=1)
Index Cond: (user_id = 3649)
Total runtime: 5718.592 ms

最佳答案

更新:看起来你的查询基本上是这样的

with cte as (
select r.test_id
from responses as r
where r.user_id = 333
union all
select c.parent_id
from tests as c
inner join responses as r on r.test_id = c.id
where r.user_id = 333
)
select
t.id
from tests as t
where
t.id in (select c.test_id from cte as c) or
t.parent_id in (select c.test_id from cte as c)

old:试着把它变成这个查询,看看它是否会更快:

select t.id 
from tests t
inner join tests c on c.parent_id = t.id

union all

select t.id
from tests t
inner join tests c oN c.parent_id = t.parent_id

执行这些查询之一需要多长时间?

关于sql - 为什么这个 LEFT JOIN 运行缓慢?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18606373/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com