Индекс с несколькими столбцами, использующий только первый столбец

Question

Если у меня есть таблица с многостолбцовым индексом (OrderId, OrderType) и мое предложение where использует первый столбец индекса, полезен ли этот индекс?

Является ли индекс немного менее эффективным, чем если бы у меня был индекс (OrderId), возможно, там, где очень большое количество строк?

Насколько я понимаю, многоколонный индекс полезен при использовании там, где критериив первом столбце, даже если я не возвращаю второй столбец в select или используя where.Однако мой опыт работы с Oracle меньше, чем у других механизмов БД, и мне сказали, что многостолбцовый индекс не используется, если я не ссылаюсь на оба столбца в моем запросе.Кроме того, анализатор плана рекомендует создавать индекс по одному столбцу для OrderId, когда индекс уже существует (OrderId, OrderType).Поэтому создается впечатление, что создание индекса из одного столбца (OrderId) является излишним.

Не пытаясь проанализировать мой запрос.Просто пытаюсь установить, неправильно ли я понимаю что-то фундаментальное с многоколоночными индексами в Oracle.

Спрашивается по-другому:

Если бы у меня уже был индекс (OrderId, OrderType), было бы когда-нибудьМожет ли быть ситуация, когда было бы полезно также создать индекс (OrderId)?

select OrderId, Amount
from Orders
where OrderDate > i_startSearchDate and OrderDate < i_endSearchDate
and OrderId in (
   select OrderFk from Items where ItemType = 1
);

Answer 1

Oracle, безусловно, может использовать индекс для OrderID, OrderType для этого запроса.Ожидает ли оптимизатор того, что будет более эффективно использовать этот индекс или выполнять сканирование таблицы (или использовать какой-либо другой индекс), будет зависеть от таких вещей, как число OrderID значений, которые, как ожидается, будут возвращены вIN список и какая доля строк в таблице, которая представляет.Тот факт, что сканирование индекса требует больше операций ввода-вывода при наличии дополнительных столбцов, также будет фактором, который учитывает оптимизатор, но это не должно быть огромным фактором.Если оптимизатор прав, что составной индекс будет медленнее, чем сканирование таблицы, а сканирование таблицы будет медленнее, чем индекс только на OrderID, вполне вероятно, что все три из этих планов доступа будут занимать очень похожее количество времени.