Oracle Indexes

Neo Nomaly
Дата: 14.03.2011 11:54:10
Поясните пожалуйста, чем отличается создание индекса на двух столбцах сразу, от 2х индексов на каждом из этих столбцов...

Индексирует ли оракл автоматически столбцы, которые отмечены, как один из концов внешнего ключа?
AlexFF__|
Дата: 14.03.2011 12:05:07
Neo Nomaly
... как один из концов внешнего ключа?
wurdu
Дата: 14.03.2011 12:08:43
Составной индекс может быть полезен при условиях по двум столбцам одновременно. Два отдельных индекса могут использоваться одновременно в специфичных случаях, при bitmap-конвертациях и при bitmap индексах. Составной индекс может быть неэффективен при условии только по одному из столбцов. Столбец в child таблице автоматически не индексируется, т.к. эти индексы нужны не во всех случаях.
Neo Nomaly
Дата: 14.03.2011 12:32:01
Вот у меня идут запросы SELECT SMTH FROM SMTBL WHERE ...

И в этом WHERE соответственно периодически меняются значение столбцов, причем некоторые там могут отсутствовать...

Сейчас проиндексирован каждый столбец в отдельности, по которому идет выборка... Насколько это эффективно/неэффективно?
Perepil
Дата: 14.03.2011 12:38:34
Ежели индексы построены по одному столбцу, то в принципе оптимизатор может использовать до 5 таких индексов на одну таблицу если в WHERE эти столбцы используются в качестве условий типа:
поле1='значение1' and поле2='значение2' and поле3='значение3'
Ключевое слово для поиска AND_EQUAL.

Ежели индекс составной, то желательно наличие в запросах условие по обоим полям, ну или хотя бы по первому полю в индексе.
Хотя в зависимости от значений полей составного индекса оптимизатор вполне может составить план выполнения, когда он будет использовать только условие по второму полю.
Ключевое слово для поиска INDEX_SKIP_SCAN
wurdu
Дата: 14.03.2011 12:43:39
Neo Nomaly
Вот у меня идут запросы SELECT SMTH FROM SMTBL WHERE ...

И в этом WHERE соответственно периодически меняются значение столбцов, причем некоторые там могут отсутствовать...

Сейчас проиндексирован каждый столбец в отдельности, по которому идет выборка... Насколько это эффективно/неэффективно?
Надо анализировать запросы, характер распределения данных, селективность условий по столбцам. Анализировать производительность. Универсального ответа нет.
Perepil, начиная с 10g вместо AND_EQUAL используется BITMAP CONVERSION FROM ROWIDS, BITMAP CONVERSION TO ROWIDS. И это должна быть очень специфичная ситуация чтобы оптимизатор выбрал это преобразование вместо одного из индексов.
Perepil
Дата: 14.03.2011 15:58:26
wurdu,

Спасибо. Старею... Не поспеваю...
Tolka
Дата: 14.03.2011 21:41:43
wurdu
начиная с 10g вместо AND_EQUAL используется BITMAP CONVERSION FROM ROWIDS, BITMAP CONVERSION TO ROWIDS. И это должна быть очень специфичная ситуация чтобы оптимизатор выбрал это преобразование вместо одного из индексов.


а специфичность эту как-то можно описать?

При наличии выборки по полям, которые проиндексированны различными индексами, я довольно часто наблюдал в планах индексный джоин. И думал, что это нормальная ситуация, нежели специфичная...
wurdu
Дата: 15.03.2011 01:43:51
Tolka
wurdu
начиная с 10g вместо AND_EQUAL используется BITMAP CONVERSION FROM ROWIDS, BITMAP CONVERSION TO ROWIDS. И это должна быть очень специфичная ситуация чтобы оптимизатор выбрал это преобразование вместо одного из индексов.


а специфичность эту как-то можно описать?

При наличии выборки по полям, которые проиндексированны различными индексами, я довольно часто наблюдал в планах индексный джоин. И думал, что это нормальная ситуация, нежели специфичная...
BITMAP CONVERSION FROM ROWIDS используется когда есть ряд неэффективных индексов на колонках с низкой селективностью, которые по одиночке не будут использоваться. Часто это связано с проблемами в дизайне, когда просто индексируются все поля. Эффективнее строить составной индекс или несколько bitmap. Но, конечно, можно представить ситуации, когда комбинирование B-tree может быть полезным. Например, в OLTP, когда bitmap индексы нежелательны из-за блокировок, а compressed B-tree индексы в принципе приводят к нужному результату, или когда проиндексированы внешние ключи и индексы все равно есть.
_Nikotin
Дата: 15.03.2011 15:08:48
Добавлю что ещё есть HASH INDEX JOIN