【问题标题】:Continuation, I am wondering why it produces tremendous file while should not have produced?继续,我想知道为什么它会产生巨大的文件而不应该产生?
【发布时间】:2012-08-08 15:11:09
【问题描述】:

Continuation

select a.artno, a.name 
from Art a 
inner join store s on a.Artno <> s.Artno` 

运行此查询花费了我超过 1 分钟的时间,产生了更多的 899K 行,而本应产生 7.9K 的结果。

select artno 
from art 
except 
(select artno from store)

这行代码为我提供了 7.9K 行,这对我来说是正确的。

第一个代码似乎是工作代码,但需要一些时间并产生大量结果集。想知道为什么?

【问题讨论】:

    标签: sql-server-2008 inner-join


    【解决方案1】:

    &lt;&gt; 运算符与INNER JOIN 一起使用通常不是一个好主意,除非你真的知道你想要很多记录。换句话说,JOIN 是一个很好的包含而不是排除的工具。

    当您使用 &lt;&gt; 运算符(尤其是键)执行 INNER JOIN 时,查询会返回 artstore 记录的每个组合,但 Artno 键匹配的位置除外。

    因此,如果您有 4 条 art 记录和 5 条 store 记录,其中只有一条具有匹配的 ArtNo 值,那么您最终将得到 4 x 5 - 1 = 19 条记录。

    第二个查询仅显示不在任何商店中的所有 art 记录。

    【讨论】:

    • 非常感谢您的澄清。这就是我一直在寻找的。​​span>
    【解决方案2】:

    这两个查询是不同的。第一个查询是连接两个表的结果,虽然条件可能相同,但根据您的结果,它是两个表之间的一对多关系。

    相比之下,第二个查询不是连接两个结果,而是从 ART 表中选择并排除您从另一个表中提供的艺术编号。

    最后,第二个查询需要更长的时间而不知道很多关于您的数据库的原因是一个猜测,但我会试一试。

    第一个瓶颈是它连接两个显然不是一对一的表,但第二个瓶颈可能是索引或左侧表的大小。请记住,在像这样的 JOIN 中,左手表被扫描,理想情况下右手是搜索。

    这有意义吗?

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2019-08-30
      • 2019-10-25
      • 2015-12-02
      • 2019-07-23
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多