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