与where子句相比，dateadd()在on条件下是否很慢？

Question

我在select中遇到了一种情况，如果我将dateadd()从on-condition移动到where-clause，它会变得更快。

但有时可能无法将其从on-condition移动到where-clause。我的解决方案是将dateadd()从on-condition移到一个临时表中，这加快了整个存储过程的速度。

但我想知道：dateadd()在on-condition中比其他地方慢真的是真的吗？

Answer 1

除非我能找到准确的Sybase引用，否则我将回答SQL Server的一些引用，但所有查询优化器的工作方式都类似

首先，谓词上的DATEADD函数会使索引使用无效(请参阅number 2 here)。

ON子句当然是谓词的形式(想想旧的隐式-JOIN-in-WHERE语法)，所以同样适用。

现在，查询遵循logical processing step (如果不是实际的，这就是“查询优化器”被称为“查询优化器”的原因)。在此之前，哪里是其中之一。

在WHERE子句中使用DATEADD时，它是一个残差过滤器，因为在ON子句中已经完成了限制行的主要工作。如果DATEADD在ON子句中，则它比WHERE子句“更快”得到处理。

这与Sybase JOIN docs状态相同

...the优化器只能考虑列名称上的索引。任何类型的运算符或表达式与列名的组合都意味着优化器不会使用列上的索引作为可能的访问方法进行计算。如果联接中的列属于不兼容的数据类型，优化器只能考虑对其中一列进行索引。

查询处理顺序在此Sybase doc中得到提示

实际上，同样的事情也适用于左连接中的外部表过滤器:在这种情况下，WHERE子句在左连接之后太晚了。或者为什么不存在总是胜过LEFT JOIN ..为空。查看适用于Sybase OUTER JOINS的内容

DATEADD本身并不是问题所在:是逻辑查询处理顺序使它看起来像一个