与where子句相比，dateadd（）在开启条件下缓慢吗？

Question

我有一个select的情况，如果我将dateadd()从on条件移到where条款，它会变得更快。

但有时可能无法将其从on条件和where条款。我的解决方案是将dateadd()从on条件移到临时表，而这会加速整个存储过程。

但我还在想; dateadd()在on条件下比其他地方更慢吗？

Answer 1

我将与SQL Server的一些参考答案，除非我能找到确切的Sybase引用，但所有的查询优化器的工作同样

首先，在谓词DATEADD函数无效索引的使用（见number 2 here）。

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

现在，查询荣誉logical processing step（如果不是真实的，这就是为什么“查询优化器”被称为如此）。在WHERE之前开启是其中之一。

使用WHERE子句中的DATEADD，它是一个残留过滤器，因为主要工作已在ON子句中完成以限制行。如果DATEADD在ON子句中，则它将比WHERE子句“更早”处理。

这是按Sybase JOIN docs状态

...优化只能考虑列名的索引。与列名称结合使用的任何类型的运算符或表达式意味着优化程序不会使用列上的索引作为可能的访问方法进行评估。如果联接中的列是不兼容的数据类型，那么优化器可以只考虑其中一列的索引。

查询处理顺序在此Sybase doc

同样的道理也适用于外部表过滤器LEFT JOINS暗示，真正做到：在WHERE子句是为时已晚后LEFT JOIN这种情况下。或者为什么NOT EXISTS几乎总是击败LEFT JOIN .. IS NULL。看到这个为Sybase OUTER JOINS

DATEADD本身是没有问题的：它是逻辑查询处理顺序，使得它出现一个