Мдя...

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

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