我发现自己陷入了困境。我有只有一列（抑制或包含列表）的表，它们或多或少是 varchar(25)，但问题是我没有时间在主查询中使用它们之前对它们进行索引，并且取决于它的重要性，我不知道每个表中有多少行。所有这一切的核心基表是大约 140 万行和大约 50 列。
我的假设如下：
在返回大量值（行）的情况下不应该使用 IN，因为它看起来是连续的，对吗？ （子查询上的 IN 没有直接传递值）
联接（INNER 用于包含和 LEFT 并在抑制时检查 Null）最适合大型数据集（超过 1k 行左右）
EXISTS 一直让我担心，因为它似乎对每一行（全部 140 万？哎呀。）进行子查询。
我的直觉说，如果可行，请获取抑制表的计数并使用 IN（对于 1k 行以下）和 INNER/LEFT 联接（对于 1k 行以上的抑制表）注意，我将要抑制的字段将是大基表中的索引，但抑制表不会。想法？
在此先感谢您提供任何和所有 cmets 和/或建议。
【问题讨论】：
标签： sql sql-server tsql join exists
假设 TSQL 表示SQL Server, have you seen this link regarding a comparison of NOT IN, NOT EXISTS, and LEFT JOIN IS NULL？综上所述，只要被比较的列不能为NULL，NOT IN和NOT EXISTS比LEFT JOIN/IS NULL效率更高...
关于 IN 和 EXISTS 之间的区别需要牢记 - EXISTS 是一个布尔运算符，并在第一次满足条件时返回 true。尽管您在语法中看到了相关子查询，但 EXISTS 的性能优于 IN...
此外，IN 和 EXISTS 仅检查值比较是否存在。这意味着没有像您在加入时发现的重复记录...
这真的取决于，所以如果你真的想找到性能最好的，你必须测试和比较查询计划正在做什么......
【讨论】：
无论您使用什么技术，如果您应用过滤器或连接的表上没有索引，系统将执行表扫描。
RE：存在
系统不一定会对所有 140 万行进行子查询。 SQL Server 足够聪明，可以执行内部 Exists 查询，然后根据主查询对其进行评估。在某些情况下，Exists 的性能可以等于或优于 Join。
【讨论】：