Сложный SQL лечится не магией, а разбором плана и узких мест

Сложный SQL лечится не магией, а разбором плана и узких мест

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

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

Частая ошибка — пытаться «ускорить» запрос добавлением индекса на каждое поле подряд. Посмотрим, что тут с I/O в реальности: если план упирается в плохой join, индекс на стороне справочника не спасет. Иногда сильнее помогает переписать подзапрос в EXISTS, убрать лишний DISTINCT, разбить CTE, который мешает оптимизатору, или заранее агрегировать данные.

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

Итог простой: оптимизируют не SQL как язык, а конкретный план выполнения. Сначала находите, где запрос раздувается, потом режете этот участок, а не лечите всё одним индексом.