Большая разница в производительности: использование sysdate против использования предварительно отформатированной даты - PullRequest
8 голосов
/ 02 июня 2011

Почему такая огромная разница в производительности между этими двумя запросами?

-- (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 и 2 других столбца.Индекс также существует для mydate.Оба б-дерева.В нем около 29 миллионов строк.

Почему оптимизатор выбрал для них такой явно иной (и в одном случае ужасный) план?

Ответы [ 2 ]

6 голосов
/ 02 июня 2011

Джонатан Льюис написал о проблемах с sysdate в 9i; Взгляните, например, на раздел «1002 * удивительного sysdate» здесь . По сути, арифметика на sysdate, похоже, сбивает с толку оптимизатор, поэтому в этом случае он считает, что индекс на mydate является более избирательным. Это кажется довольно экстремальным примером. (Первоначально указывалось в этом направлении из сообщения «Не спрашивайте Тома»).

1 голос
/ 02 июня 2011

Я не знаю Oracle, но в Postgresql возможный источник игнорирования индекса - несовпадающие типы. Возможно, прямая - 5 заставляет Oracle думать, что число числовое. Можете ли вы выполнить приведение на сегодняшний день (или любой другой тип точного типа mydate) на sysdate - 5?

...