Как ответить
Короткий ответ: да, будет, но не всегда так эффективно, как при фильтрации по первой колонке. Всё зависит от того, какая колонка используется и как построен индекс.
Составной индекс — это B-дерево, где ключи сортируются сначала по первой колонке, потом по второй и так далее. Если вы фильтруете только по второй колонке, СУБД может либо полностью просканировать индекс (Index Scan), либо сделать табличный доступ (Table Scan), если индекс слишком широкий.
Рассмотрим на примере:
CREATE INDEX idx_user_status_date ON users(status, created_at);Запрос WHERE status = 'active' — индекс будет использован полностью, потому что первая колонка — status. А вот запрос WHERE created_at > '2024-01-01' — индекс может быть использован только если СУБД решит, что это выгоднее полного сканирования таблицы. Для PostgreSQL или MySQL с InnoDB это будет Index Scan: база пройдёт по всем записям индекса, отфильтрует по created_at и сделает Lookup в таблицу для остальных полей.
Есть исключение — Covering Index (покрывающий индекс). Если в индексе лежат все поля, которые нужны запросу, СУБД может сделать Index Only Scan даже при фильтрации по второй колонке. Например:
SELECT created_at FROM users WHERE created_at > '2024-01-01';Здесь индекс покрывает запрос — база прочитает только индекс, не трогая таблицу.
Важный нюанс: в Oracle и SQL Server есть Index Skip Scan — оптимизация, которая позволяет эффективно искать по второй колонке, разбивая индекс на логические сегменты по первой колонке. Но это работает только если значений в первой колонке немного (например, статус 'active'/'inactive'). В PostgreSQL такого нет, поэтому фильтр по второй колонке почти всегда будет Index Scan, а не Seek.
Итог:
- Если фильтр по первой колонке — индекс работает на 100%.
- Если по второй — зависит от СУБД, селективности и покрытия.
- Всегда проверяйте через EXPLAIN — теория может расходиться с практикой.