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` после выката.