Сложный SQL не лечат индексом вслепую: сначала разберите план, потом код

Сложный SQL не лечат индексом вслепую: сначала разберите план, потом код

Коллеги, давайте разберем план выполнения. В сложных запросах обычно ломается не «SQL вообще», а один из узких мест: лишний full scan, тяжелый join, сортировка на больших объемах или повторный расчет одного и того же подзапроса.

Что проверять первым:
— есть ли фильтр, который реально сокращает строки до join;
— не тащит ли CTE/подзапрос лишние данные;
— не превращает ли функция по колонке условие в неиспользуемый индекс;
— совпадает ли порядок соединений с селективностью условий.

Дальше смотрим на форму запроса. Иногда запрос быстрее становится не от «умного» переписывания, а от простого разбиения: вынести агрегацию до join, заменить correlated subquery на предварительный набор, убрать DISTINCT, если он маскирует ошибку в логике. Если сортировка дорогая — проверяйте, нельзя ли отдать данные уже в нужном порядке через индекс или сократить набор до нее.

И главное: оптимизация без измерений — это гадание на буферах. Сначала мониторинг, потом индексы. Снимите план, посмотрите I/O, оценки vs фактические строки, блокировки и время на каждом операторе. Один и тот же запрос может быть быстрым на тесте и убивать продакшен на пике нагрузки.

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