Пытаясь оптимизировать один сложный запрос столнулся с неодназным поведением оптимизатора при построении Плана запроса.
Суть: надо заставить таблицы (в реале вьюшки, но я буду упрощать где можно) соединяться с right outer hash join в определенном порядке. При нормальных параметрах сервер сам выстраивает подобное соединение и использует фильтр по всем таблицам. Но когда я пытаюсь заставить его использовать только right hash хинтом, сервер использует фильтр лишь на основной таблице, что приводить к дикому сканированию по остальным.

Попытался воспроизвести простой пример на основе этой статьи .

код:

версия: 2008R2 (10.50.6529.0)

В моем реальном случае использовать первый вариант нет возможности.
Вопрос: почему сервер тупит в такой очевидной ситуации? и как его заставить?

Подскажите, пожалуйста, в какую сторону копать.

Ennor TiegaelIdol_111,

У меня пятничный затуп наверное, но в примере 1, когда условие на Т3 помещается в where, соотв. внешний джойн разве не превращается во внутренний?
в этом простом случае он превращается в inner join, ну так ничего не мешает так же сделать и во 2м случае. Разве нет?

Ennor TiegaelIdol_111,

У вас там 3 неиндексированные кучи, и вы джойны гвоздями прибивать пытаетесь. Может, сначала с индексами поколдовать? Оно и оптимизатору попроще будет, и вам.
Спасибо за совет, за индексы не беспокойтесь, я не первый раз оптимизацию провожу :).
Вы лучше по существу чего-нибудь предложите.

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

Простой пример из ссылки (где можно найти коды для создания таблиц и самому все протестировать) лишь показывает, на мой взгляд, не достаточно "умное" поведение сервера при построении запроса. Кажется, что когда используются хинты сервер перестает понимать что T3.a = T1.b и можно использовать фильтр по обеим таблицам.

Мой случай гороздо сложнее (поэтому речь не о нем сейчас), там 9 вьюшек вложенных (5уровней) и соединенных сложным образом с кучей условий на каждой.
Кстати, поэтому не могу использовать OPTION(HASH JOIN) - View.
И самая проблематичная вьюха как раз и состоит в основном из 8 LEFT joins, но при построение "хорошего" плана сервер соединяет их через RIGHT OUTER JOIN. Что я и попытался возпроизвести жестко задав все хинтами и переписав вьюху чуток. Однако, в таком случае сервер отказывается использовать фильтры, которые заданы в конечном скрипте. Т.е. когда сам строит план использует фильтры, а когда с хинтами, уже не хочет и выходит жесткий скан по куче таблиц.
К примеру, вместо чтения 108 строк по таблице (когда с фильтром) идет скан 12 млн. строк.

Мой вопрос был: возможно ли победить подобную тупизну или нет?

Для тех кто сам хочет проверить и дан был простой пример.

Ennor TiegaelВозможно, ТС не видит разницы между его 2-мя запросами.
А вот здесь поподробней пожалуйста. И какова разница между этими двумя запросами? Неужели результат? :)

Ennor TiegaelВы не поверите:

Ну почему же не поверю, поверю. Особенно когда так профессионально ткнут носом :).
Спасибо. Вы натолкнули меня на мысль, а то похоже у меня реально глаз "замылился".