Сложный SQL не лечится магией: сначала план, потом индексы и переписывание

Сложный SQL не лечится магией: сначала план, потом индексы и переписывание

Коллеги, давайте разберем план выполнения. У тяжёлого запроса обычно три причины: лишние строки в ранней стадии, плохой порядок соединений и функции/выражения, которые убивают использование индекса. Начинать надо не с «добавим ещё один индекс», а с проверки факта: сколько строк читает каждый шаг, где идёт сортировка, и не тащит ли запрос весь набор туда, где нужен один ряд.

Что обычно помогает:
— протолкнуть фильтры как можно раньше;
— убрать `SELECT *`, если половина колонок не нужна;
— заменить коррелированные подзапросы на `JOIN` или `EXISTS`, если это уменьшает повторные проходы;
— не оборачивать индексируемый столбец в функции в предикате;
— проверить, не делает ли CTE/VIEW лишнюю материализацию. Посмотрим, что тут с I/O в реальности.

Отдельно следите за `OR`, `NOT IN`, `DISTINCT` и `ORDER BY` без нужного покрытия. Эти конструкции часто выглядят безобидно, а потом внезапно дают full scan и большой temp. Если запрос начал «тормозить после добавления одного условия», ищите не только селективность, но и то, как оптимизатор пересобрал план.

Золотое правило: сначала мониторинг, потом индексы. Если план уже понятен, переписывайте минимально и проверяйте эффект на объёме, близком к продакшену. В продакшене так лучше не делать, и вот почему: красивый SQL без плана — это просто дорогой текст.