gpt4 book ai didi

SQL - NOT IN 内的查询比完整查询花费的时间更长?

转载 作者:行者123 更新时间:2023-12-02 10:36:14 26 4
gpt4 key购买 nike

我在 SQL 查询中使用 NOT IN。

例如:

select columnA 
from table1
where columnA not in (
select columnB
from table2)

这部分查询怎么可能

select columnB
from table2

需要 30 秒才能完成,但上面的整个查询需要 0.1 秒才能完成?完整的查询不应该花费 30 秒以上吗?

顺便说一句,两个查询都返回有效结果。

谢谢!

评论回复

Is it because the second query hasn't actually completed but has only returned back the first 'x' rows (out of a very large table?)

不,查询在 30 秒后完成,返回的行数不多(例如 50 行)。

But @Aleksandar wondered why the question congaing the performance killer was so fast.

我的观点完全正确

Also how long does select distinct columnB from table2 take to execute?

实际上,原始查询是“select different...

最佳答案

您似乎认为您的主要查询意味着以下步骤:

(1)  Run the subquery
(2) Check each row in table1 against the result set from the subquery.

因此,您认为单独运行子查询一定比运行整个查询花费更少的时间。

但是 SQL 不是一种过程语言,查询的结构并不一定意味着执行查询所遵循的步骤。

正如 Guffa 回答的那样,优化器将提出(它认为的)执行每个查询的最佳计划。从查询来看,这些执行计划并不总是显而易见的,并且在某些情况下确实可能非常违反直觉。

我认为,在这种情况下,优化器很可能想出了一种更快的方法来检查 table2 中是否存在某个值,而不是简单地一次查询所有 table2。这可能是 Guffa 所展示的转换(尽管这仍然没有告诉您正在使用的确切执行计划)。

我猜想 table1 的行数明显少于 table2,并且 table2.columnB 上存在索引。因此,它所要做的就是从 table1 中获取行,然后探测每个值的索引以检查是否存在。但这只是一种可能。

此外,正如 Michael Buen 指出的那样,返回结果集大小的差异也会影响您感知的性能。我的直觉是,这对于执行计划差异来说是次要的,但它可能很重要。

关于SQL - NOT IN 内的查询比完整查询花费的时间更长?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4604446/

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