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

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

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

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

Дальше режем запрос по слоям: убираем подзапросы, которые можно заменить join’ом или CTE только для читаемости; выносим фильтры как можно раньше; проверяем, не ломает ли функция в WHERE использование индекса. Если условие выглядит «удобно», но превращает поиск в скан — это плохое удобство.

Особое внимание — повторяющимся агрегациям, OR по разным полям и неявным преобразованиям типов. Именно они часто делают план нестабильным: на маленьком объеме все летает, на боевом — внезапно начинается I/O-ад. Посмотрим, что тут с I/O в реальности.

Золотое правило: сначала мониторинг, потом индексы. Если после переписывания запрос все еще тяжёлый, только тогда добавляем индекс под конкретный предикат и проверяем, не выросла ли цена записи и блокировок.