SQL Server中的相关查询与内部联接性能

我刚刚运行了一个测试查询,两个语句最终得到了完全相同的执行计划。当然,对于任何性能问题,我建议您在自己的环境中运行测试;使用SQL Server Management Studio,这很容易(如果您运行的是2000,则使用SQL查询分析器)。只需在查询窗口中键入这两个语句,选择查询包含实际查询计划。然后运行查询。转到“结果”选项卡,您可以很容易地看到计划是什么,以及哪个计划的成本更高。

奇怪的是:通常情况下,我更自然地首先将这些作为相关查询来编写,在这种情况下,我必须返回并重新考虑使用联接,因为根据我的经验,SQL Server优化器更有可能做到这一点。

但别把我当回事。尽管我在这里有2.6万个代表,而且是目前仅有的两个特定于SQL主题的徽章中的一个,但就SQL知识而言,我实际上还比较初级(这都是关于容量的问题)。我当然不是DBA。在实践中,您当然需要对每个方法进行概要分析,以衡量它的实际性能。我愿意 期待 优化器可以识别您所请求的内容,并以最佳方式处理这两个查询,但在检查之前您永远不会知道。

使用连接。如果您有小表,它可能不会对性能产生很大的影响,但是如果“外部”表非常大,那么它将需要对每一行执行exists子查询。如果您的表是在公共列上建立索引的,那么执行内部联接应该快得多。顺便说一句,如果要查找第二个表中没有的所有行,请在第二个表中使用左联接并测试空值——这比在拥有非常大的表和索引时使用exists快得多。

正如每个人注意到的,这都归结为优化器。我建议以您觉得更自然的方式编写它,然后确保优化器能够找出最有效的查询计划(收集统计数据,创建索引,随便什么)。SQL Server优化器总体上很好,只要您提供它需要使用的信息。

最好的性能可能是与派生表的联接。存在可能是下一个(并且可能更快)。最糟糕的性能是在select中使用子查询,因为它倾向于逐行运行,而不是作为一个集合运行。

然而,所有的东西都是平等的,数据库性能非常依赖于数据库设计。我会尝试所有可能的方法,看看在你的情况下哪个更快。