Сложный SQL не лечат «магией» — его разбирают по плану выполнения

Сложный SQL не лечат «магией» — его разбирают по плану выполнения

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

Рабочий порядок такой:
— Проверить фактический план, а не надежду оптимизатора.
— Сократить набор данных до JOIN: фильтры, предикаты, предагрегация.
— Убрать функции с колонок в WHERE и ON, иначе индекс часто превращается в декорацию.
— Смотреть на кардинальность: если оценка мимо, план легко уедет в nested loop на миллионы строк.

Частая ошибка — лечить симптом индексом на каждое поле. Индекс помогает, когда селективность есть и запрос умеет его использовать. Если проблема в GROUP BY, DISTINCT или лишнем CTE-материале, индекс только ускорит путь к той же ошибке. Посмотрим, что тут с I/O в реальности: иногда дешевле переписать подзапрос в semijoin или вынести тяжелую агрегацию в отдельный шаг.

Отдельно следите за сортировками и блокировками: ORDER BY без нужного индекса, широкие SELECT *, долгие транзакции и конкурирующие UPDATE легко превращают «просто отчет» в источник боли. В продакшене так лучше не делать, и вот почему...

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