2

我发现自己陷入了困境。我有只有一列(抑制或包含列表)的表,它们或多或少是 varchar(25),但问题是我没有时间在主查询中使用它们之前对它们进行索引,并且取决于它的重要性,我不知道每个表中有多少行。所有这一切的核心基础表是大约 140 万行和大约 50 列。

我的假设如下:

IN 不应该用于返回大量值(行)的情况,因为它看起来是连续的,对吧?(子查询上的 IN 没有直接传递值)

连接(INNER 用于包含和 LEFT 并在抑制时检查 Null)最适合大型数据集(超过 1k 行左右)

EXISTS 一直让我担心,因为它似乎在为每一行做一个子查询(全部 140 万?哎呀。)

我的直觉说,如果可行,请获取抑制表的计数并使用 IN(对于 1k 行以下)和 INNER/LEFT 连接(对于 1k 行以上的抑制表)注意,我将要抑制的字段将是大基表,但抑制表不会。想法?

提前感谢您的任何和所有评论和/或建议。

4

2 回答 2

6

假设 TSQL 是指SQL Server,您是否看过这个关于 NOT IN、NOT EXISTS 和 LEFT JOIN IS NULL 比较的链接?总之,只要被比较的列不能为NULL,NOT IN并且NOT EXISTSLEFT JOIN/IS NULL...

关于 IN 和 EXISTS 之间的区别需要牢记 - EXISTS 是一个布尔运算符,并在第一次满足条件时返回 true。尽管您在语法中看到相关子查询,但 EXISTS 的性能优于 IN...

此外,IN 和 EXISTS 仅检查值比较是否存在。这意味着没有像您在加入时发现的重复记录......

这真的取决于,所以如果你真的想找到什么表现最好,你必须测试和比较查询计划正在做什么......

于 2010-08-30T20:42:03.573 回答
0

无论您使用什么技术,如果您应用过滤器或连接的表上没有索引,系统将执行表扫描。

回复:存在

系统不一定会对所有 140 万行进行子查询。SQL Server 足够聪明,可以执行内部 Exists 查询,然后根据主查询对其进行评估。在某些情况下,Exists 的性能可以等于或优于 Join。

于 2010-08-30T20:41:24.730 回答