Индексы: как они работают и когда помогают

индекс — это вспомогательная структура, ускоряющая поиск ценой места и записи.

Почему это важно: Большая часть медленных запросов лечится правильным индексом. Но неправильный индекс делает только хуже.

Главная идея

Индекс — это отсортированная структура (обычно B-tree), позволяющая находить нужные строки за O(log n) вместо O(n).

Как это выглядит на практике

Запрос WHERE email = ? сканирует всю таблицу — медленно.
Создаём индекс по email — БД ищет нужную строку по дереву.
Запрос ускоряется в сотни раз.
INSERT в таблицу замедляется — теперь нужно обновлять и индекс.

Что происходит под капотом

B-tree — структура индекса по умолчанию в большинстве СУБД.
Hash-индексы быстрее для точного равенства, но не работают для диапазонов.
Составной индекс (a, b, c) полезен для запросов по a, по a+b и по a+b+c, но не по b или c отдельно.
Покрывающий индекс (covering index) содержит все нужные поля — БД не идёт в таблицу.
Частичный индекс — индекс только по подмножеству строк (например, WHERE active = true).

Типичные ошибки и заблуждения

Ошибка: индексы всегда ускоряют. Они замедляют записи и занимают место.
Ошибка: 'добавим индексы на всё'. БД может просто перестать ими пользоваться.
Ошибка: индекс сразу применяется. Иногда оптимизатор решает не использовать его.
Ошибка: порядок колонок в составном индексе не важен. На самом деле очень важен.

Ключевые выводы

Индекс — это компромисс: чтение vs запись.
Составной индекс — самый недопонятый.
Покрывающий индекс убирает обращения к таблице.
Без EXPLAIN нельзя быть уверенным, что индекс используется.

Термины урока

B-tree — сбалансированное дерево, основа большинства индексов.

Selectivity — насколько индекс хорошо разделяет строки.

Covering index — индекс, содержащий все нужные колонки запроса.

Index-only scan — план, в котором БД не читает саму таблицу.

Связь с работой backend-разработчика

Backend-разработчик должен уметь читать план запроса и понимать, какой индекс нужен под нагрузку приложения.

Мини-разбор реальной ситуации

Запрос профиля пользователя занимал 800 мс под нагрузкой. Добавление составного индекса (user_id, created_at) сократило время до 4 мс — без изменений в коде.

Что запомнить

Индекс — это компромисс.
Порядок колонок в составном индексе важен.
Проверяй EXPLAIN перед выводом в прод.

Итог

Индексы — самый мощный инструмент производительности БД, если их применять осознанно.