Собственно сам вопрос: В каких ситуациях левый джойн может быть быстрей inner join?


Update:
Сам пример:
Sql Sever 2008
Есть две вьюхи Documents(Документы) и Payments(Выплаты по документам), и одна таблица Banks(тот кто выплачивает).

Отношения: Documents(1) - Payments(n)
Documents(n)-Banks(1).

Количество записей, примерно:
Payments: 250 тыс
Documents: 35 тыс
Banks: 8 тыс.
Код 

выполняется за пятнадцать секунд, а если left заменить на inner, то запрос после десяти минут ожидания приходилось останавливать самому.
Documents.BankID может быть пустым.

Это сообщение отредактировал(а) Kolovorot - 26.6.2012, 16:31

Вы уж определитесь...

Левый и правый суть одно и то же.
inner, как указано в заголовке темы и left, right суть разные вещи.


В тех, когда планы запроса для левого и правого отличаются в не выгодную для правого пользу 

SQL - декларативный язык. Он не определяет то, как результат должен быть получен. Он определяет каким он должен быть. В идеале, два по разному сформулированных запроса, описывающих одну и ту же выборку, на одном и том же наборе данных, с одинаковым значением параметров, должны выполняться одинаково. Если это не так, это обуславливается лишь не совершенством современных оптимизаторов.

Это сообщение отредактировал(а) Zloxa - 26.6.2012, 16:13

Ой точно опечатался.  Благодарю поправил конечно имел в виду left vs inner.

Это разные по сути операции.
inner join может быть выражен через left, наоборот - нет.

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

Это сообщение отредактировал(а) Zloxa - 26.6.2012, 16:25

Обновил топик с вопросом  

Не увидел в топике вопроса.
Вам нужно чтобы inner работал с той же скоростью, с какой работает left? Смотрите в план в чем разница. Вероятнее всего выбирается другой порядок объединения таблиц. Как тут реагировать - зависит от платформы. Обновлять статистику, добавлять хинты...

Край, закостылиться можно попробовать добавив where bank.id is not null. Результат будет эквивалентен inner join


Вью на вью на вью = смерть.

DDL в студию.

И чо, действительно думаешь мозг поломать над эпическими джойнами во вьюхах?   
Тогда советую реквестнуть сразу и планы для обоих кейсов  

Уже костылился - результат аналогичен inner join был  .

А про вью на вью где почитать можно. Потому как реализовал нужный мне функционал из вьюхи Documents  в запросе - запрос стал выполняться за 15 сек.

Добавлено через 52 секунды

К сожалению нельзя  

тут практика - критерий истины.  
Но объяснение просто. Дано: сложная вью. Сверху сложной вью громоздим другую сложную вью. У оптимизатора два выхода. Использовать первую вью как Inline, второй - раскрыть вью и попытаться их функционал объеденить. В первом случае окажется что выполнено много не нужной работы ибо часть работы, которая делает первая вью, для результата второй, в принципе - не необходима. Результат - не оптимален. Во втором случае, у оптимизатора увеличивается глубина дерева вероятных планов и увеличивается шанс оптимизатору запутаться и выдать не оптимальный план.

К сожалению, да, на данном этапе развития оптимизаторов, повторное использование в SQL оказываетя весьма и весьма череватым.


А вот и она - практика   

Это сообщение отредактировал(а) Zloxa - 26.6.2012, 19:39