Может ли БД использовать несколько индексов в запросе?

Развёрнутый ответ: Использование нескольких индексов в одном запросе

Да, современные системы управления базами данных (СУБД) действительно могут использовать несколько индексов в рамках одного запроса. Это важная оптимизационная техника, которая позволяет существенно ускорить выполнение сложных запросов, особенно тех, которые содержат условия фильтрации по разным столбцам или включают операции соединения (JOIN).

Механизмы использования нескольких индексов

СУБД применяют различные стратегии для комбинирования нескольких индексов:

1. Индексное сканирование с последующим соединением (Index Scan + Merge/Intersection)

Наиболее распространённый подход. СУБД выполняет отдельное сканирование по каждому релевантному индексу, получая промежуточные наборы идентификаторов строк (ROWID или первичных ключей), а затем объединяет эти наборы с помощью операций AND или OR перед финальным обращением к таблице.

-- Пример запроса, где могут использоваться два индекса
SELECT * FROM orders 
WHERE customer_id = 123 AND status = 'shipped';

Если существуют отдельные индексы по customer_id и status, СУБД может:

• Использовать индекс по customer_id для поиска всех заказов клиента 123.
• Использовать индекс по status для поиска всех заказанных со статусом 'shipped'.
• Выполнить операцию пересечения (INTERSECT) этих двух наборов ROWID.
• Обратиться к таблице только по итоговым совпадающим идентификаторам.

2. Комбинированные индексы (Составные/композитные индексы)

Хотя технически это один индекс, он эффективно покрывает несколько столбцов и часто является альтернативой использованию нескольких отдельных индексов.

-- Создание составного индекса
CREATE INDEX idx_customer_status ON orders(customer_id, status);

-- Для запроса выше такой индекс будет идеален и, скорее всего, 
-- предпочтительнее использования двух отдельных индексов.

3. Использование нескольких индексов в операциях JOIN

При выполнении соединений таблиц оптимизатор может использовать индексы из каждой из соединяемых таблиц для быстрого поиска соответствий.

SELECT u.name, o.total 
FROM users u 
JOIN orders o ON u.id = o.user_id
WHERE u.country = 'RU' AND o.status = 'processed';

Здесь могут быть задействованы:

• Индекс по users.country для фильтрации пользователей из России.
• Индекс по orders.user_id для быстрого поиска заказов конкретного пользователя (часть JOIN).
• Индекс по orders.status для фильтрации только обработанных заказов.

Ключевые факторы, влияющие на решение оптимизатора

1. Селективность условий — Если условие по одному индексу отфильтровывает 95% строк, а по другому — только 50%, СУБД может предпочесть использовать только первый индекс, так как обращение ко второму может оказаться излишне затратным.

2. Оценка стоимости (Cost-Based Optimization) — Современные оптимизаторы (особенно в PostgreSQL, Oracle, SQL Server) оценивают предполагаемую стоимость операций ввода-вывода и использования CPU для разных планов выполнения, включая варианты с несколькими индексами.

3. Наличие статистики — Актуальная статистика по распределению данных в таблицах и индексах критически важна для принятия правильного решения.

4. Типы индексов — Некоторые индексы (например, bitmap-индексы в Oracle) специально оптимизированы для быстрого комбинирования через логические операции. В PostgreSQL существует специализированный метод доски Bitmap Index Scan, который эффективно строит битовые карты по нескольким индексам и комбинирует их.

Пример из реальной практики (PostgreSQL)

EXPLAIN ANALYZE 
SELECT * FROM large_table 
WHERE category_id = 5 AND tags @> ARRAY['sale'] AND created_at > '2024-01-01';

-- В плане выполнения можно увидеть:
-- Bitmap Heap Scan on large_table
--   Recheck Cond: ((category_id = 5) AND (created_at > '2024-01-01'::date))
--   Filter: (tags @> '{sale}'::text[])
--   ->  BitmapAnd
--         ->  Bitmap Index Scan on idx_category  -- Используется первый индекс
--               Index Cond: (category_id = 5)
--         ->  Bitmap Index Scan on idx_created   -- Используется второй индекс
--               Index Cond: (created_at > '2024-01-01'::date)

Здесь явно видно, как PostgreSQL использует операцию BitmapAnd для объединения результатов сканирования двух индексов (idx_category и idx_created).

Ограничения и подводные камни

• Непомерный рост сложности — При наличии 5 подходящих индексов оптимизатору придётся оценивать десятки возможных комбинаций, что может замедлить этап планирования запроса.
• Требования к статистике — Устаревшая статистика часто приводит к субоптимальным решениям о комбинировании индексов.
• Накладные расходы на объединение — Операции пересечения/объединения промежуточных результатов имеют свою стоимость и не всегда эффективнее использования одного подходящего составного индекса.
• Зависимость от СУБД — Поведение сильно различается между разными СУБД. MySQL/InnoDB, например, до версии 8.0 в большинстве случаев мог использовать только один индекс на таблицу в запросе (за исключением index merge). В то время как PostgreSQL, Oracle и SQL Server имеют более развитые механизмы.

Вывод

Использование нескольких индексов в одном запросе — это мощный инструмент оптимизации, но не панацея. Эффективность такого подхода зависит от конкретной СУБД, структуры данных, распределения значений и актуальности статистики. Для критически важных запросов всегда рекомендуется анализировать план выполнения (EXPLAIN plan) чтобы убедиться, что выбранная стратегия (включая возможное комбинирование индексов) является оптимальной для ваших данных и нагрузки. В долгосрочной перспективе правильно спроектированные составные индексы часто оказываются более предсказуемым и эффективным решением.