intermediate

Indexes

Ускоряйте access paths через B-tree и specialized indexes, оплачивая write, memory и maintenance cost.

Индекс — вспомогательная структура доступа, чаще B-tree, позволяющая находить строки по ключу без полного scan таблицы. Каждый индекс ускоряет часть чтений и облагает каждую запись, затрагивающую индексируемые столбцы.

| Форма индекса | Типичное применение | |---------------|---------------------| | Одностолбцовый B-tree | Равенство/диапазон по одному предикату | | Составной `(a, b, c)` | Многостолбцовые фильтры; действует правило left-prefix | | Covering (с доп. столбцами) | Index-only scan без обращения к heap | | Partial `WHERE active` | Меньший индекс для горячего подмножества | | Hash / GIN / GiST | Зависит от движка: равенство, JSON, geo, full-text |

					CREATE INDEX idx_orders_user_created
  ON orders (user_id, created_at DESC)
  WHERE status <> 'cancelled';
				

Проектируйте от реальных форм запросов: ведущий столбец — самый селективный equality-фильтр; не индексируйте отдельно флаги с низкой кардинальностью. Следите за write amplification, bloat и неиспользуемыми индексами в production.

На интервью: для медленного запроса предложите индекс и объясните цену для записи и хранения.

Типовые ошибки: индекс на каждый столбец в `WHERE`; неверный порядок столбцов в composite; избыточные перекрывающиеся индексы; нет индекса на FK-столбцах; создание индексов до замера планов.

Компромисс — между латентностью чтения и пропускной способностью записи, памятью и обслуживанием (vacuum/rebuild): добавляйте индексы под доказанные горячие пути, а не под гипотетические фильтры.

Чеклист:

  • Процитируйте точный предикат и `ORDER BY`, под которые индекс.
  • Упорядочите столбцы composite по селективности и left-prefix.
  • Укажите covering-столбцы, если цель — index-only scan.
  • Явно назовите цену для записи и хранения.
  • Запланируйте проверку через `EXPLAIN` после выката.