Есть ли какие-либо преимущества в определенном порядке столбцов при определении индексов

13

Например, если у меня есть два индекса:

CREATE INDEX IDX_1 ON MY_TABLE_1
 (ITEM, DATE, LOCATION)
 COMPUTE STATISTICS;

CREATE INDEX IDX_2 ON MY_TABLE_1
 (DATE, LOCATION, ITEM)
 COMPUTE STATISTICS;

Будет ли это сделать IDX_2излишним? Если нет, то как определить порядок объявления столбцов?

Должен ли я адаптировать индексы к обычным запросам?

oracle index

— Льюис Нортон
источник

12

Да, выгода приходит, когда вы хотите запросить часть индекса. Если сначала поставить частично использованные предикаты, индекс можно использовать для запросов, которые включают эти предикаты, но не все столбцы в индексе.

Кроме того, если у вас нет других требований, это может помочь поставить самые селективные предикаты первыми, поскольку это может ускорить операции поиска по индексу.

В вашем случае IDX_2это не обязательно избыточно в зависимости от характера запросов к таблице. Однако может быть необязательно включать все столбцы. Если, например, вы выполняете много запросов, locationи dateтогда IDX_2может быть полезно помочь разрешить эти запросы, так как IDX_1это не в том порядке, чтобы быть полезным для этого. Вы можете, однако, обнаружить, что itemэто избыточно IDX_2.

Начиная с 9i, Oracle представила оператор «пропустить сканирование», в котором конечные столбцы индекса можно запрашивать более эффективно, что может снизить потребность в дополнительных индексах такого рода.

В более конкретном случае, если вы запрашиваете itemна locationи dateи не нужны никакие другие столбцы , то запрос может быть полностью решена , хотя индекс без ничего из таблицы читать. Вы также можете создавать закрывающие индексы, к которым прикреплены неиндексированные столбцы. Если все необходимые столбцы могут быть разрешены из индекса покрытия, запрос вообще не должен касаться главной таблицы.

Наконец, в ответ на ваш последний вопрос: если у вас есть набор регулярно используемых запросов, которые используют много ресурсов и могут быть настроены с использованием индекса, то это, безусловно, стоит рассмотреть. Однако поддержание индексов сопряжено с накладными расходами на вставки, поэтому вам придется сопоставлять производительность запросов с накладными расходами, которые индексы накладывают на операции вставки или обновления.

— ConcernedOfTunbridgeWells
источник

3

@ConcernedOfTunbridgeWells: альтернативный подход состоит в том, чтобы использовать сжатие индексного ключа и иметь менее избирательные (с меньшим количеством различных значений) ведущие столбцы. Это помогает привести к меньшему индексу, в то же время позволяя пропуску сканирований работать хорошо.

— Адам Муш

2

Еще одна вещь, которую следует учитывать, - это столбцы с большим количеством нулевых значений.

Если в этих столбцах есть какие-либо столбцы, указанные после них в индексе, нулевые значения должны быть проиндексированы. В противном случае, как обычно, нулевые значения не индексируются (конечно, это предполагает, что вы используете индекс b-дерева).

Таким образом, если у вас есть столбцы с большим количеством нулевых значений, размещение их в конце индекса может сэкономить вам значительный объем дискового пространства.

— Михал Тененберг
источник