TSQL——on 子句的顺序是否重要答案

【问题标题】：TSQL -- Does ordering of on clause matterTSQL——on 子句的顺序是否重要
【发布时间】：2021-07-20 21:14:47
【问题描述】：

对于简化查询：

Select t1.c1, t1.c2, t2.d1
FROM table1 t1
LEFT JOIN table2 t2
ON
(t1.c1 = t2.d2)

从数学的对称属性看来，这与将 ON 反转为：完全相同：

Select t1.c1, t1.c2, t2.d1
FROM table1 t1
LEFT JOIN table2 t2
ON
(t2.d2 = t1.c1)

这在 TSQL 中是否始终为真，或者是否存在一些例外情况，即如果查询如上文所述被巧妙地更改，则可以获得更多行？

我了解到非常细微的联接更改（在比这个简单示例复杂得多的查询中）会极大地影响行数。

此外，除了返回的行（我认为这两个查询始终应该完全相同）之外，我认为“ON”子句的一种排序可以使查询具有更好的性能速度。有人可以验证吗？

【问题讨论】：

有趣的是，就在我发布此内容之前，来自 StackOverflow 的自动建议之一是：stackoverflow.com/questions/14415881/…——这当然看起来是一个有价值的任务，但它与我的上面的问题！哈哈
表的连接顺序对结果和性能很重要，如果使用正确的表连接顺序，它不会影响性能，并且第一个和第二个查询中的 on 子句将运行为相同的。如果您检查实际的查询计划和统计信息，您将观察到两个查询相同。但是，如果您有 where 子句或更改了加入顺序，您的结果会有所不同，例如 Performance。使用 set statistics io 设置统计信息，您将能够了解统计信息的定量测量
如果您在 Joining 列上有索引，您的性能将比在普通列上 join 更好。
表中的行没有顺序。结果集 [原文如此] 仅按照最外层顺序具有（“部分”）顺序。这个问题（正如可以预料的那样）也是一个常见问题解答。查询优化/实现的基础也是如此。请在考虑询问之前进行研究。 How to Ask Help center PS “思考”文档中无法指出的事情是没有帮助的。
看看实际的执行计划看看有什么不同。（我不希望有任何结果。）结果将是相同的，尽管没有明确的order by 子句的行没有预期的顺序。 查询优化器将使用索引（如果有的话）和它们的统计数据来确定（可能的）最好的方式来继续执行语句。

【解决方案1】：

正如您所观察到的，任何类型的 JOIN 中的 ON 条件都可以是可交换的。您可以使用ON a = b 或ON b = a 并让它们的含义完全相同。它们只是布尔表达式。

【讨论】：