Oracle SQL query - неожиданный план запроса

У меня очень простой запрос, который дает неожиданные результаты. Мы будем рады получить подсказки о том, где искать неисправности.

В упрощенном виде запрос выглядит так:

SELECT Obs.obsDate, 
       Obs.obsValue, 
       ObsHead.name
  FROM ml.Obs Obs 
  JOIN ml.ObsHead ObsHead ON ObsHead.hdId = Obs.hdId
 WHERE obs.hdId IN (53, 54)

Это дает мне стоимость запроса: 963. Однако, если я изменю запрос на:

SELECT Obs.obsDate, 
       Obs.obsValue, 
       ObsHead.name
  FROM ml.Obs Obs 
  JOIN ml.ObsHead ObsHead ON ObsHead.hdId = Obs.hdId
 WHERE ObsHead.name IN ('BP SYSTOLIC', 'BP DIASTOLIC')

Хотя он (должен) возвращать те же данные, ориентировочная стоимость возрастает до 17688. В чем, вероятно, заключается проблема? Спасибо.

Изменить: план запроса говорит, что индекс на ObsHead.Name используется для сканирования диапазона, а доступ к таблице в ObsHead стоит только 4. Есть еще один индекс на Obs.hdId, который используется для сканирования диапазона стоимостью 94 : это соединение вложенных циклов между таблицами, которое увеличивается до 17К.


sql plsql sql-execution-plan oracle10g
person SarekOfVulcan    schedule 10.03.2010    source источник
comment
Можете ли вы поделиться EXPLAIN PLAN для обоих запросов?   -  person Guru    schedule 11.03.2010

Ответы (4)


arrow_upward
1
arrow_downward

Как уже было сказано, стоимость плана не предназначена для сравнения двух разных запросов, а предназначена только для сравнения разных путей для одного и того же запроса.

Это только предположение, но в этом случае поле количества элементов плана может быть для вас более полезным. Если индекс в OBSHEAD не уникален и статистика была собрана с использованием оценки, тогда оптимизатор может не знать точно, сколько строк ожидать при запросе этой таблицы. Количество элементов скажет вам, верно это или нет (в идеале вы увидите количество элементов 2 для OBSHEAD).

Еще одно предложение - проверить статистику по OBS. Кажется вероятным, что это таблица, которая часто растет, и в этом случае 28 января еще недостаточно для сбора статистики. Предполагая, что для этой таблицы включен мониторинг, приведенные ниже запросы могут сказать вам, устарела ли статистика и ее необходимо обновить.

select owner, table_name, last_analyzed, stale_stats
from all_tab_statistics
where owner = 'ML' and table_name = 'OBS';

select owner, index_name, last_analyzed, stale_stats
from all_ind_statistics
where owner = 'ML' and table_name = 'OBS';
person Allan    schedule 12.03.2010

arrow_upward
1
arrow_downward

Вероятно, есть индекс на hdId (который есть, если это первичный ключ, что, как я подозреваю, так и есть), а не на name, что означает, что второй запрос должен будет выполнить полное сканирование таблицы.

person Klaus Byskov Pedersen    schedule 10.03.2010
comment
Нет, это не то, что происходит. Подробнее см. Мою правку выше. - person SarekOfVulcan; 10.03.2010
comment
@SarekOfVulcan: Ваша статистика актуальна? Какая разница в реальном времени выполнения? - person Klaus Byskov Pedersen; 10.03.2010
comment
Статистические данные для этих двух таблиц последний раз анализировались 28 января, поэтому они достаточно близки к актуальным. Я не уверен, каков обычный график их анализа - у нас есть VAR, который обычно заботится об этом за нас. Я не уверен, в чем разница во времени выполнения - я выполнял вышеуказанное как часть гораздо более длительного запроса, который вчера занял более 8 часов. - person SarekOfVulcan; 10.03.2010

arrow_upward
1
arrow_downward

Стоимость полезна только для сравнения разных планов для одного запроса; они не так полезны для сравнения разных запросов.

Вам нужно посмотреть на планы и сравнить их с точки зрения выполняемых действий.

Я подозреваю, что фактическая производительность этих запросов будет аналогичной, однако было бы интересно узнать, использует ли первый запрос хеш-соединение, которое может помочь, если процент сопоставленных записей в obs является значительным.

person Jeffrey Kemp    schedule 11.03.2010

arrow_upward
1
arrow_downward

Я считаю, что затраты, предоставляемые оптимизатором, интересны, но не особенно полезны. Лучший способ, который я нашел для сравнения запросов, - это запустить их и посмотреть, как они работают относительно друг друга.

Делитесь и наслаждайтесь.

person Bob Jarvis - Reinstate Monica    schedule 11.03.2010