與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本身是沒有問題的：它是邏輯查詢處理順序，使得它出現一個