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

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

Рабочий чек-лист простой: — убрать SELECT * и вернуть только нужные поля; — вынести фильтры как можно раньше, особенно по датам и статусам; — заменить коррелированные подзапросы на JOIN или CTE, если это снижает повторные проходы; — проверить, не ломает ли выражение в WHERE использование индекса. Схема простая, но дьявол кроется в статистике: кривые оценки кардинальности легко превращают хороший план в прогулку по всему массиву данных.

Посмотрим, что тут с I/O в реальности. Если запрос упирается в чтение, индекс может помочь только при точном совпадении по предикату. Но если вы фильтруете по функции от колонки, приводите типы на лету или тянете слишком широкий диапазон, оптимизатор часто выбирает full scan не из вредности, а потому что так дешевле.

Еще один частый провал — лишняя работа на сортировке и агрегации. Если можно сократить набор строк до GROUP BY, делайте это до JOIN’ов, а не после. И да: временная таблица иногда честнее, чем один монструозный запрос. В продакшене так лучше не делать, и вот почему... Но если план становится понятнее и дешевле по I/O, это нормальный инженерный компромисс.

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