Индекс (база данных)

Индекс базы данных — это вспомогательная структура данных, обычно B-дерево или похожая упорядоченная структура, построенная по одному или нескольким столбцам таблицы, чтобы сделать поиск по этим столбцам значительно быстрее, чем сканирование каждой строки. Без индекса поиск конкретной строки (`WHERE email = 'user@example.com'`) требует, чтобы база данных проверила буквально каждую строку таблицы («последовательное сканирование» или «сканирование таблицы») — приемлемо для нескольких сотен строк, губительно для нескольких миллионов. Почему это важно для разработчиков AI/SaaS: индексирование — одно из наиболее эффективных и наименее трудозатратных вмешательств в производительность, и его отсутствие — ведущая причина классической жалобы «приложение стало медленным по мере роста». Оно отличается от — но концептуально связано с — «индексом», который векторная база данных строит поверх эмбеддингов (индекс эмбеддингов): оба обменивают накладные расходы записи и дополнительное хранение на более быстрое чтение, просто над очень разными видами данных и с использованием очень разных базовых структур (B-деревья для точных/диапазонных совпадений по скалярным значениям, HNSW/IVFFlat для приближённого сходства по векторам высокой размерности). Как это работает: типичный B-tree индекс хранит значения столбца в отсортированном порядке вместе с указателем обратно на полную строку, так что база данных может провести бинарный поиск до нужного значения вместо линейного сканирования — превращая поиск O(n) примерно в O(log n). Индексы следует добавлять на столбцы, часто используемые в условиях `WHERE`, условиях `JOIN` и предложениях `ORDER BY` — но не бездумно, потому что каждый индекс добавляет накладные расходы к каждой операции `INSERT`/`UPDATE`/`DELETE` (сам индекс тоже нужно обновлять) и потребляет дополнительное дисковое пространство; чрезмерное индексирование таблицы с интенсивной записью — реальная и распространённая ошибка. Составные индексы (охватывающие несколько столбцов, например `(customer_id, created_at)`) ускоряют запросы, фильтрующие или сортирующие именно по этой комбинации, но менее полезны для запросов, затрагивающих только второй столбец отдельно, из-за особенностей упорядочивания B-дерева — тонкость, которая сбивает с толку многих в работе по оптимизации запросов. Практический пример: таблица `events` многотенантного SaaS вырастает до 40 миллионов строк; запрос панели, фильтрующий `WHERE customer_id = ? AND created_at > ?`, начинает занимать 6+ секунд как последовательное сканирование. Добавление составного индекса `CREATE INDEX idx_events_customer_created ON events (customer_id, created_at);` снижает этот же запрос до менее 10 мс, потому что Postgres теперь может перейти напрямую к релевантным строкам для этого клиента и временного диапазона, вместо чтения всей таблицы при каждой загрузке панели. Команда также запускает `EXPLAIN ANALYZE` для запроса до и после, чтобы подтвердить, что планировщик запросов действительно выбрал использование нового индекса, а не проигнорировал его — шаг, который стоит сделать привычным, поскольку индекс, который существует, но не используется (частый результат неудачного порядка столбцов в составном индексе), не даёт никакой выгоды, но всё равно оплачивает полную стоимость времени записи.