2017-01-26 4 views
2

Я настраиваю запрос для большой транзакционной финансовой системы. Я заметил, что включение условия соединения в предложение where , а также предложение from делает запрос выполняемым значительно быстрее, чем любой из двух в отдельности. Я отмечаю, что соединение в предложении from имеет более одного условия; Я упоминаю об этом, если это важно. Вот упрощенный пример: Добавление условия соединения в предложении from и * where делает запрос быстрее. Зачем?

SELECT * 
FROM  employee e 
INNER JOIN car c ON c.id = e.car_id AND -- some other join 
-- Adding the join above again, in the where clause makes the query faster 
WHERE c.id = e.car_id; 

Я думал ANSI против старой школы была чисто синтаксической. Что происходит?

Update

Проанализировав два плана выполнения, то ясно, что добавление такой же присоединиться к ИНЕКЕ как из пункта, производит совершенно иной план исполнения, чем имея присоединиться к любой из двух.

Сравнивая планы, я мог видеть, что план с дополнительным условием, где условие условия делалось лучше, и задавался вопросом, почему тот, у кого нет, соединяется так, как это было. Зная оптимальный план, быстрая настройка условий соединения разрешила вопросы, хотя я все еще удивляюсь, что оба запроса не скомпилировались в одно и то же. Черная магия.

+2

Было бы интересно увидеть планы объяснений; можете ли вы опубликовать их? Кроме того, какая версия Oracle? – Aleksej

+0

Да, это довольно интересно. Для SQL Server это чисто семантическое. –

+0

@Aleksej Боюсь, я не могу, я буду нарушать политику безопасности на работе. Спасибо за вашу помощь! –

ответ

1

может быть тем, что добавление WHERE c.id = e.car_id - это способ управления порядком, в котором таблицы используются для правильного поиска. Это может быть способ заставить оптимизатор запросов использовать как главная таблица таблица, в которой условие и таблица связаны с тем, что последовательность соединений в таблице не может быть так достоверна для поиска, как полезно для понимания логики запроса.

+0

Я думаю, что это то, что происходит. Добавление проверки в предложение where изменяет порядок соединения в плане выполнения. Я собираюсь экспериментировать с подсказкой ORDERED и посмотреть, могу ли я получить такое же поведение без повторного состояния. –

+0

@RobertBain. попробуйте и дайте мне знать ... если вы имеете в виду последовательность, в которой соединение является ручкой, это помнит меня, как повлиял на оптимизатор запросов, когда нет явного соединения sintax, и все таблицы были написаны бок о бок запятыми. то самое правильное было названо ведущей таблицей, потому что было оценено сначала в сканировании таблицы. Может быть также с явным присоединением к новому оптимизатору запросов, которое эта концепция теряется, а затем где зависимость усиливает это поведение .. надеюсь, что комментарий полезен. – scaisEdge

+0

scaisEdge, см. Обновление выше. У меня нет окончательного ответа. –