where查询是IN查询还是另一个表的子查询?

我用需求创建了一个数据库,并对它进行了测试。 从“计时”的角度看,其实没有区别,但可能是因为我的测试沙盒环境。

1- select * from users where id in (1,2,3,4,5,6,7,8,9,10,..3000)

成本 =4.04..1274.75行=3000宽度=11)“索引条件:(id=ANY('{1,2,3,4,5,6,7,8,9,10(…)”

2- SELECT * FROM users AS u WHERE EXISTS (SELECT 1 FROM lookuptable A-- l WHERE u.id = l.id); <- 请注意,我已经删除了'distinct',它是无用的。

成本:“合并半联接”( =103.22..364.35行=3000宽=11英寸)

“合并条件:(u.id=l.id)”

成本

“—>使用users\u pkey对users\u进行索引扫描( 成本 =0.29..952.68行=30026宽=11“)

3- Select * from users where id IN (select id from lookuptable)

“合并半联接”( 成本

“合并条件:(users.id=lookuptable.id)”

“—>使用用户索引扫描\u pkey on users( 成本

“—>仅索引扫描使用lookuptable\u pkey on lookuptable( =0.28..121.28行=3000宽=4“

无论如何,正如我从上面的一些评论中读到的,您还必须将填充lookuptable的成本添加到查询的成本中。。 而且,您必须将“查询”拆分为不同的执行,这可能会导致“事务性问题”。 我将使用第一个查询。

在PostgreSQL中,最快的方法是创建一个查找表并进行如下查询:

SELECT * FROM users AS u
WHERE EXISTS (SELECT 1 FROM lookuptable AS l
              WHERE u.id = l.id);

最好的方法是在工作数据集上使用explain analyze。 sql explain 它将显示查询执行时间和查询路由。

查询优化器可以根据表大小、数据库设置、内存设置等使用不同的技术。

如果查找表只有3000条记录,您不需要在其上使用distinct,如果它确实很大并且有更多的记录,distinct可以创建3000条唯一的记录,那么第一种解决方案可能会更快。