<b>Индексы: как не убить запись ради ускорения одного отчёта</b>

<b>Индексы: как не убить запись ради ускорения одного отчёта</b>

Коллеги, давайте разберем план выполнения. Индекс — это не «ускоритель всего», а компромисс между чтением и записью. Ошибка №1: ставить B-Tree на каждый столбец подряд. Ошибка №2: держать дублирующие и пересекающиеся индексы — они съедают место, замедляют INSERT/UPDATE и путают оптимизатор.

Схема простая, но дьявол кроется в статистике. Сначала ищем запросы с реальным больным местом: дорогие сканы, сортировки, nested loop на больших объёмах, частые фильтры и JOIN по ключам. Затем смотрим селективность: если колонка почти всегда одинаковая, индекс на ней часто бесполезен. Если запрос выбирает 30–40% таблицы, оптимизатор нередко честно выберет full scan — и это нормально.

Дальше — стратегия. • Составной индекс строим под шаблон WHERE + JOIN + ORDER BY, а не «на всякий случай». • Порядок колонок важен: сначала самые селективные и используемые в фильтре. • Для покрывающих запросов добавляем только нужные поля, без фанатизма. • Не забываем про maintenance: чем больше индексов, тем дороже массовые загрузки и перестроения 🛠️

Перед созданием индекса проверьте: он реально попадёт в запрос, не дублирует ли уже существующий, не ломает ли планы на соседних запросах. Золотое правило: сначала мониторинг, потом индексы. Иначе получаете красивую схему и медленный продакшен.