Индексы не лечат медленные запросы — они лечат конкретный план выполнения

Индексы не лечат медленные запросы — они лечат конкретный план выполнения

Коллеги, давайте разберем план выполнения. Индекс нужен не «на всякий случай», а под реальный паттерн доступа: фильтрация, соединение, сортировка, покрытие. Если запрос выбирает 80% таблицы, B-tree часто только добавит I/O и лишнюю работу на запись.

Базовая стратегия простая:
— сначала ищем самые частые WHERE и JOIN;
— потом смотрим ORDER BY и GROUP BY;
— отдельно проверяем селективность: низкая селективность = слабая польза;
— не плодим дубли: составной индекс часто заменяет два одиночных, если порядок колонок верный.

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

Золотое правило: сначала мониторинг, потом индексы. Смотрите фактический план, число чтений, долю сканов, влияние на INSERT/UPDATE/DELETE и блокировки. Если индекс не уменьшает чтения и не ускоряет типовой запрос, его место — в черновике, а не в продакшене.

Итого: индексируем под конкретный запрос и измеряем эффект, а не верим интуиции.