Индексы ускоряют чтение, но могут убить запись: где проходит разумная граница

Индексы ускоряют чтение, но могут убить запись: где проходит разумная граница

Коллеги, давайте разберем план выполнения. Индекс нужен не «на всякий случай», а под конкретный паттерн: фильтр, сортировка, соединение, уникальность. Если запросов под него нет — это балласт, который съедает I/O и место, а при вставках еще и блокирует лишнюю работу.

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

Посмотрим, что тут с I/O в реальности. Частая ошибка — «индекс на каждую колонку». В итоге оптимизатор получает россыпь слабых индексов, а не один полезный. Еще хуже — индекс с низкой селективностью: по нему план красивый, а чтение почти как full scan. Золотое правило: сначала мониторинг, потом индексы.

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

Индекс без измерения — это не оптимизация, а ставка на удачу. Схема простая, но дьявол кроется в статистике: сначала нагрузка, потом план, потом индекс.