Сложный SQL тормозит не из-за «плохого сервера», а из-за лишней работы

Сложный SQL тормозит не из-за «плохого сервера», а из-за лишней работы

Коллеги, давайте разберем план выполнения. Типовая ошибка — лечить запрос индексом, не поняв, где он тратит время: на full scan, сортировку, hash join или повторные чтения. Сначала смотрим фактический план, а не догадки: где выросли строки, где сломалась селективность, где optimizer выбрал дорогой путь.

Дальше чистим сам запрос:
— убираем SELECT *, если тащите лишние колонки;
— не прячем фильтр в функцию над полем, если нужен поиск по индексу;
— заменяем коррелированные подзапросы на JOIN или EXISTS, если это снижает повторные проходы;
— делим монстра на этапы через CTE или временные таблицы, когда это помогает зафиксировать промежуточный набор.

Золотое правило: сначала мониторинг, потом индексы. Часто узкое место не в отсутствии индекса, а в неверной форме условия, плохой статистике или слишком широкой выборке. И да, «добавим еще один индекс» иногда просто ускоряет запись и усложняет жизнь всем остальным.

После правок снова смотрим план и фактические чтения. Если картина не меняется, значит проблема не в синтаксисе, а в модели данных, кардинальности или доступе к большим объемам I/O.

Схема простая, но дьявол кроется в статистике: сначала найдите лишнюю работу, потом уберите ее из запроса.