巨大的性能差異：使用sysdate vs使用預格式化日期

爲什麼這兩個查詢之間存在如此巨大的性能差異？巨大的性能差異：使用sysdate vs使用預格式化日期

-- (89 seconds) 
SELECT max(mydate) FROM mytable WHERE eqpid = 'ABCDEFG' 
AND mydate < sysdate - 5

與不管指標

-- (0.6 seconds) 
SELECT max(mydate) FROM mytable WHERE eqpid = 'ABCDEFG' 
AND mydate < TO_DATE('05/27/2011 03:13:00', 'MM/DD/YYYY HH24:MI:SS') -- 5 days ago

，似乎都TO_DATE和SYSDATE剛剛回歸「一些日期值」。

注：此表上存在一個組合索引，包括eqpid和其他兩列。 mydate也存在索引。兩者都是B型樹。大約有2900萬行。

爲什麼優化器會爲這些計劃選擇一個明顯不同的（並且在某種情況下是可怕的）計劃？

來源

2011-06-01 Charles Burns

「eqpid」索引中的列表是什麼？是列表列下的「eqpid」組合索引？如果是這樣，那麼Oracle可能會認爲它不是一個有效的類型索引，因此它會懲罰該計劃。 – btilly 2011-06-01 21:47:05

@btilly：這種情況下的組合主鍵包括3列：eqpid（varchar2 8字節），rectype（varchar1 1字節），serialnobyte（數字）。我的理解是，eqpid是關鍵中的第一個可以使用索引。 – 2011-06-02 14:08:25

是的，它應該能夠這樣做，並在第二個查詢中完成。但是你顯然有很多這種eqpid的行，當它認爲它有另一種選擇時它肯定會迴避它。優化器可以做奇怪的事情。（但是當我需要讓MySQL運行復雜的查詢時，我很想念它。） – btilly 2011-06-02 14:47:22

喬納森劉易斯在9i寫了關於sysdate的問題;例如，查看「令人驚訝的sysdate」部分here。本質上sysdate上的算術似乎混淆了優化器，所以在這種情況下，它認爲mydate上的索引更具選擇性。這看起來像是一個非常極端的例子。（最初從一個不真正相關的Ask Tom帖子指向這個方向）。

來源

2011-06-01 22:10:14

即使Oracle讓我們通過QA，我也感到很驚訝。 – 2011-06-01 22:16:27

+1，我隱約記得閱讀有關這個，但無法找到參考;-) – DCookie 2011-06-01 22:32:24

你的意思是更有選擇性，而不是更少選擇性？ – btilly 2011-06-02 14:43:29

我不瞭解Oracle，但在Postgresql中忽略索引的可能來源是不匹配的類型。也許直接做- 5讓Oracle認爲rhs是數字。你是否可以在sysdate - 5上進行演員表演（或者其他什麼是確切的 mydate類型）？

來源

2011-06-01 21:50:56

巨大的性能差異：使用sysdate vs使用預格式化日期

回答

相關問題