<b>Сложный SQL можно ускорить без магии: сначала уберите лишнюю работу</b>

<b>Сложный SQL можно ускорить без магии: сначала уберите лишнюю работу</b>

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

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

Посмотрим, что тут с I/O в реальности. Если план показывает Seq Scan там, где вы ждете Index Scan, сначала смотрите на селективность и типы сравнений, потом уже на индексы. Частая ошибка — оборачивать поле функцией: WHERE date(created_at) = ... почти всегда хуже, чем диапазон по исходному столбцу.

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

Если запрос тяжёлый, режьте объем данных раньше, а не лечите симптомы на финальной сортировке.