Индексируйте более чем колонну только с 5 отличными значениями - Стоящий того?

Question

Индексируйте более чем колонну только с 5 отличными значениями - Стоящий того?

Запустите энергию с измененной локали:

LC_ALL=en_GB.utf-8 vim

Или экспорт, что переменная на значение по умолчанию в Вашем bashrc/profile.

8

oracle indexing

задан svrist 10 December 2009 в 09:10

5 ответов

Индекс будет полезен в следующих случаях:

При поиске нечастых FREQUENCYID . Например, только 10 из ваших 10 000 000 строк имеют FREQUENCYID = 1 , и вы выполняете поиск.
Если вы не используете другие столбцы, кроме FREQUENCYID в ваших запросах. Этот запрос:
```
 SELECT FREQUENCYID, COUNT (*)
ИЗ mytable
ГРУППА ПО
 FREQUENCYID
```
выиграет от индекса (на самом деле, INDEX FAST FULL SCAN вместе с HASH AGGREGATE , скорее всего, будет использоваться)
Когда ваши строки таблицы большие и все столбцы вы использование в запросе индексируются. Таким образом, все индексы будут объединены вместо выполнения ПОЛНОГО СКАНИРОВАНИЯ ТАБЛИЦЫ . Скажем, этот запрос:
```
 SELECT FREQUENCYID, OTHERCOLUMN
ИЗ mytable
ГДЕ FREQUENCYID = 2
```
может быть выполнен путем объединения значений из индексов на FREQUENCYID и OTHERCOLUMN на ROWID .

2

ответ дан 5 December 2019 в 14:03

Если он будет увеличиваться в размере по мере того, как вы упомянули

до 5.000.000 строк

, я бы рекомендовал создать индекс.

1

ответ дан 5 December 2019 в 14:03

Протестируйте его с помощью типичных запросов, посмотрите, какой путь быстрее.

Вы можете обнаружить, что полное сканирование таблицы в среднем быстрее, чем сканирование диапазона индексов + доступ к таблице по Rowid - в котором случай Oracle понял это правильно.

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

0

ответ дан 5 December 2019 в 14:03

Возможно, самый простой способ - не угадывать, а на самом деле попробовать.

Но мне кажется, что вы сравниваете планы выполнения, чтобы найти лучший подход. Это ненадежно. Оптимизатор может не иметь соответствующей информации для выбора наилучшего плана (например, если у вас неравномерное распределение значений и нет гистограммы). Также нет смысла смотреть на «стоимость» в плане объяснения.

Лучше всего сравнивать логические операции ввода-вывода. Запустите SQL * Plus, скажем, , установите autotrace traceonly , затем запустите свой запрос (с индексом и без него) и сравните число «согласованных получений». Чем меньше, тем лучше.

О важности LIO: статья Кэри Миллсэпа .

1

ответ дан 5 December 2019 в 14:03

Другие вопросы по тегам:

oracle indexing

Похожие вопросы:

score 8 · Accepted Answer

It depends on a couple of things.

Firstly, the distribution of values. If you only have five distinct values but one of them accounts for 99.9999% of rows in the table then obviously you would not want the optimiser to use the index for that value but you might want it to use it for the others. In some cases like this it's worth using a function-based index to ensure that you only index the values of interest and not the ones that are just taking up space.

Secondly, are there queries that can be answered using that index without accessing the table?

Note that it's not just the percentage of rows that will be accessed that matters, but the number of blocks of the table that will need to be accessed. For example if you have a table of 1000 blocks and 30 rows per block on average, and one column has 30 distinct values (each one being present in 1000 rows), then the number of blocks that need to be visited to read every row for a single value varies between 1000/30=34 (worth using an index) and 1000 (not worth using an index) depending on how the rows are distributed. this is expressed by the clustering factor of the index -- if it's value is close to the number of rows in the table then the index is less likely to be used, and if it's close to the number of blocks then it's more likely to be used.

also, you might look at index compression to see if that saves you space.

Be careful with bitmap indexes -- they are not friendly to systems where they are subject to modification by multiple sessions at the same time (eg. two people both inserting rows at the same time into the indexed table).

A more effective strategy if you do want to improve the efficieny of queries with predicates on these five values is to use partitioning, partly because of partition pruning in the query but also because of the improvement in statistics available to the optimiser when it knows that only one partition will be accessed and can use partition-level statistics instead of global statistics.