Индексы — не украшение: как собрать стратегию, а не кладбище B-Tree

Индексы — не украшение: как собрать стратегию, а не кладбище B-Tree

Коллеги, давайте разберем план выполнения. Индекс нужен не «на всякий случай», а под конкретный профиль запросов: WHERE, JOIN, ORDER BY, GROUP BY. Если запросы читают 5% таблицы, индекс помогает. Если 60% — часто дешевле честный скан, чем лишний обход дерева и добор строк.

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

Посмотрим, что тут с I/O в реальности. Каждый индекс — это запись на INSERT/UPDATE/DELETE, лишняя блокировка и дополнительный расход памяти под буферы. Поэтому «добавим еще один, и все полетит» обычно заканчивается падением скорости записи. Отдельно проверяйте, не мешает ли условие использованию индекса: функции над колонкой, неявные преобразования, разные типы данных, ведущий wildcard в LIKE.

Хорошая стратегия — не максимальное число индексов, а минимальный набор под рабочие запросы. Золотое правило: сначала мониторинг, потом индексы. Снимите топ запросов, посмотрите планы, оцените чтение страниц и долю буфера, а уже потом решайте, что создавать, что объединять, а что удалить без сожаления.