<b>Сложный SQL не лечится «магией индекса»: сначала ищем лишнюю работу</b>

<b>Сложный SQL не лечится «магией индекса»: сначала ищем лишнюю работу</b>

Коллеги, давайте разберем план выполнения. У тяжёлых запросов обычно одна из трёх причин: лишние сканы, неверный порядок join’ов или раздувание строк до агрегации. Схема простая, но дьявол кроется в статистике: если оценки кардинальности врут, оптимизатор строит дорогой маршрут и потом честно его исполняет.

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

Дальше — порядок операций. Посмотрим, что тут с I/O в реальности: сначала уменьшайте набор строк, потом джойните, потом агрегируйте. Если запрос строит большой промежуточный результат, индекс на финальной таблице уже мало помогает. Частая ошибка — лечить симптом: добавили индекс, а узкое место осталось в сортировке, hash join или лишнем materialize.

Если запрос всё ещё тяжёлый, разбивайте его на этапы с временной таблицей или CTE, но без фанатизма: иногда это помогает зафиксировать хороший план, а иногда добавляет лишние чтения. В продакшене так лучше не делать, и вот почему: каждое «ускорение» надо мерить на объёме, который похож на боевой.

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