Мдя...

Я бы посоветовал прежде чем приступать к поучениям просечь вот какую тему. В FB есть два способа прибить план к запросу по получению пересечения множеств гвоздиком, а не строить их объединение и потом обрезать его ножнями по краям. Но этими способами тоже нужно пользоваться с умом, там, где это действительно требуется по двум причинам. Первая и основная - в базе исторически налеплена и используется в необозримых портянках кода, сдуру или для оптимизации некоторых запросов, куча условно полезных индексов (в зависимости от распределения значений в индексе и накладываемых на эти поля запросами условий), просто бесполезных и откровенно вредных. Обычно это касается композитных индексов. От чего у оптимизатора едет крыша. Вторая - оптимизатор, как и всё в этом мире, не идеален, он развивается, как правило, в хорошую сторону, но бывает что некоторые, для большинства разработчиков приложений экзотические, запросы при этом начинает обслуживать хуже. А почему с умом - надо всегда помнить, что сочинять жёсткие планы надо не на пустых таблицах, просто глядючи на структуру, а имея в виду не только прогнозируемые объёмы данных, но и тенденции распределения значений в индексах по мере роста этих объёмов. Оптимальный на голой структуре план при увеличении объёмов на 3-4 порядка может стать так себе, а на 8-10 просто чудовищным. Даже без зависимости от конкретных значений. И при регулярно обновляемой статистике оптимизатор с развязанными руками будет адаптироваться к этим изменениям, в 80-90% случаев именно в смысле оптимизации. Во всяком случае на односегментных индексах с более-менее ровным распределением значений. Односегментных - потому что композит, содержащий уникальное поле, всегда будет с точки зрения существующего подхода к статистике идеальным индексом и оптимизатор будет его тыкать куда ни попадя.

Резюме - вопли "шеф, всё пропало, гипс снимают, клиент уезжает" в 80-90% случаев являются следствием наложения на кривую структуру данных кривых или рискованных индексов и строительства кривых запросов. Я не утверждаю что всегда это из-за того, что разработчик приложения рановато отбросил хвост и слез с дерева, много чего в развитии предметной области либо невозможно предугадать, либо требует неприемлемых затрат времени на стадии предварительного исследования этой области и построения её модели. Долгоживущие большие системы неизбежно рано или поздно превращаются в лоскутные одеяла из заплаток, мешающих друг другу, и наступает момент перетрахивания, по-научному рефакторинга. Оставшиеся 20-10% казусов с "внезапно" возникающими тормозами относятся к случаю - в индексе мульён значений 0 и сотня 1. Когда ищется значение 1, индекс просто конфетка. А вот если карта легла так, что тот же запрос стреляет по 0 - ууууу... Вот в этом случае и приходится прибивать план гвоздиком. А не городить объединения вместо пересечений. Компрене ву?

Да какую в пень жизнь. Молодой человек, прямым текстом - освойте для начала хинты через +0 и явное указание плана, потом . можно будет и поговорить на тему когда это надо делать и когда не надо и почему, и почему плохо вместо этого применять лефт. Хотя до Вас это, похоже, не дойдёт, раз воспринимаете как беллетристику. Аргумент он привёл.

Ключевые слова подчёркнуты. Само собой, есть туева хуча запросов, в которых нужны именно внешние джойны. Есть запросы, в которых по барабану, внешний написать или внутренний, одна чорт и результат будет как у внутреннего и затратность. Типа соединения со справочником, на который есть FK. Но, согласись, Володя, в общем случае имитация внутреннего соединения путём выполнения внешнего и обрезания лишнего дополнительными условиями будет тормознее по определению. Вместо построения карты доступа к страницам данных по индексу чтение всех подряд в ведущей и уже потом усечение. А если ещё запрос представляет собой хорошо взболтанную смесь внешних и внутренних, то с ним обращаться надо как сапёру с миной.