我遇到select的情况，如果我将dateadd()条件从on条件移到where条款，它会更快。
但有时可能无法将其从on - 条件移动到where - 子句。我的解决方案是将dateadd()从on - 条件转移到临时表，然后加快整个存储过程。
但是我想知道;在dateadd()条件下on比其他地方慢吗？
答案 0 :(得分：3)
我将回答SQL Server的一些参考资料，除非我能找到确切的Sybase参考资料，但所有查询优化器的工作方式都相似
首先，谓词上的DATEADD函数使索引使用无效（参见number 2 here）。
ON子句当然是谓词的形式（想想旧的隐式JOIN-in-WHERE语法），所以同样适用。
现在，查询会尊重logical processing step（如果不是实际的话，那就是“查询优化器”被调用的原因）。在WHERE之前是ON。
在WHERE子句中使用DATEADD，它是一个残差过滤器，因为主要工作是在ON子句中完成的，以限制行。如果DATEADD在ON子句中，它将比WHERE子句“更早”处理。
这是按Sybase JOIN docs州
中暗示了查询处理顺序...优化器只能考虑列名的索引。任何类型的运算符或表达式与列名称结合使用意味着优化程序不会使用列上的索引作为可能的访问方法进行求值。如果连接中的列具有不兼容的数据类型，则优化程序可以仅考虑其中一列的索引。
同样的事情适用于LEFT JOINS中的外部表过滤器，实际上：在这种情况下，WHFT子句在LEFT JOIN之后太晚了。或者为什么NOT EXISTS几乎总是胜过LEFT JOIN .. IS NULL。请参阅Sybase OUTER JOINS
DATEADD本身不是问题：它是逻辑查询处理顺序，使其显示为一个