我养成了将连接条件与其他附加条件分开的习惯。但是我理解逻辑执行顺序是:
- 从
- 在哪里
如果我在where
子句而不是join
子句中添加附加条件,是否会损害性能;还是这部分通常在查询优化阶段得到简化和同等处理?
以下是两个返回相同计划的简单示例查询:
USE StackOverflow2010;
-- additional filters in where clause
SELECT TOP 500 p.id
FROM dbo.Posts p
INNER JOIN dbo.Votes v ON p.id = v.PostId
WHERE
v.VoteTypeId = 2
ORDER BY p.id
;
-- all criteria in on clause
SELECT TOP 500 p.id
FROM dbo.Posts p
INNER JOIN dbo.Votes v ON p.id = v.PostId AND v.VoteTypeId = 2
ORDER BY p.id
;
我想补充一点,如果我编写更长的分析语句,通常跨越 100 多行(格式化),我会尝试尽快减少结果集,通常使用派生表并在它到达连接之前添加一个额外的地方.
几乎任何“我是否以 x 方式或 y 方式写东西有关系”的问题只能回答“也许”。
优化器必须考虑很多潜在的连接路径和查询计划,他们没有太多时间来制定计划。这意味着他们最终会使用大量启发式方法来及早修剪潜在的计划树,而不是充分考虑每个可能的查询计划。因此,查询文本的微小变化可能会导致优化器修剪该计划树的方式发生一些变化,并最终产生不同的计划。
最终,回答这个问题的唯一方法是逐个查询,双向编写,然后查看计划是否发生变化。如果计划相同,那没关系。如果计划发生变化,那么这很重要。至少对于那个查询。在该版本的 SQL Server 上。使用当前的一组运行时统计信息和设置。改变任何这些东西,你必须重新评估。
实际上,这意味着您应该以最清楚地表达您的意图的方式编写查询,并让优化器完成其工作。分析应用程序时,您可以查看最耗时的查询,并考虑是否有更有效的方法来编写这些特定查询。在绝大多数情况下,优化器都会做正确的事情。在少数情况下,优化器会做一些低效的事情,您需要花费开发人员的时间来思考。
扩展SMor的评论:
对于 OUTER JOIN,无论是在 WHERE 子句上加上条件还是 JOIN 本身都可以实际改变结果。
将在 Posts 中返回记录,即使它们没有匹配的 Vote 且 VoteTypeId=2。
该
WHERE
子句抵消外连接并删除 Votes 表中没有匹配的记录。