我在 a 中遇到一种情况,select
如果我dateadd()
从on
-condition 移动到where
-clause,它会变得更快。
但有时可能无法将其从on
-condition 移至where
-clause。我的解决方案是将dateadd()
-conditionon
移到临时表中,这样可以加快整个存储过程。
但我很想知道;在 - 条件下比其他地方dateadd()
慢真的是真的吗?on
除非我能找到确切的 Sybase 参考资料,否则我将回答一些 SQL Server 参考资料,但所有查询优化器的工作方式都类似
首先,谓词上的 DATEADD 函数使索引使用无效(请参见此处的第 2点)。
ON 子句当然是谓词的形式(想想旧的implicit-JOIN-in-WHERE 语法),所以同样适用。
现在,查询尊重一个逻辑处理步骤(如果不是实际的,这就是为什么这样称呼“查询优化器”)。ON 之前 WHERE 是其中之一。
在 WHERE 子句中使用 DATEADD,它是一个残差过滤器,因为主要工作已在 ON 子句中完成以限制行。如果 DATEADD 在 ON 子句中,它会比 WHERE 子句“更快”得到处理。
这是根据Sybase JOIN 文档状态
...优化器只能考虑列名上的索引。任何类型的运算符或表达式与列名组合意味着优化器不会使用列上的索引作为可能的访问方法进行评估。如果连接中的列具有不兼容的数据类型,则优化器可以考虑仅在其中一列上建立索引。
此Sybase 文档中提示了查询处理顺序
同样的事情也适用于 LEFT JOIN 中的外部表过滤器,真的:在这种情况下,WHERE 子句在 LEFT JOIN 之后为时已晚。或者为什么不存在几乎总是胜过 LEFT JOIN .. IS NULL。有关Sybase OUTER JOINS的信息,请参见此内容
DATEADD 本身不是问题:它是逻辑查询处理顺序使它看起来像一个