Индексы без стратегии — это не ускорение, а быстрый путь к лишнему I/O

Индексы без стратегии — это не ускорение, а быстрый путь к лишнему I/O

Коллеги, давайте разберем план выполнения. Индекс ставят не «на всякий случай», а под конкретный запрос: фильтр, join, сортировку или покрытие. Если запросов много и они разные, один универсальный индекс обычно проигрывает двум-трём точечным.

Базовые правила простые:
— сначала смотрим самые дорогие запросы и фактический план, а не ощущение;
— в составной индекс выносим колонки по селективности и по порядку использования в predicate;
— не дублируем индексы, которые отличаются одной колонкой без причины;
— для низкой селективности индекс часто бесполезен, а иногда и вреден.

Посмотрим, что тут с I/O в реальности. Каждый лишний индекс замедляет INSERT/UPDATE/DELETE, раздувает бэкапы и может ухудшить план из-за неверной статистики. Схема простая, но дьявол кроется в статистике: если данные смещены, оптимизатор легко выбирает индекс, который красиво выглядит на бумаге и плохо работает на диске.

Практика: держите отдельный список «кандидатов на удаление», проверяйте unused/rarely used индексы, и перед добавлением нового смотрите, нельзя ли переиспользовать существующий через другой порядок колонок или покрытие. В продакшене так лучше не делать, и вот почему: индекс без мониторинга превращается в постоянный налог на систему.

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