2

В Oracle 11g, скажем, у меня есть таблица Task, у которой есть столбец ProcessState. Значения этой колонки могут быть Queued, Running и Complete (в будущем может быть еще несколько государств). В таблице будет 50M + данных с 99,9% строк, имеющих Complete в качестве значения столбца. Только несколько тысяч строк будут иметь значение Queued/Running.Какой индекс должен быть создан для столбцов с высокой степенью заполнения с высокой мощностью в оракуле?

Я читал, что хотя индекс bitmap хорош для столбца с низкой мощностью, но используется в основном для статических таблиц.

Итак, какой индекс может улучшить запрос для Queued/Running задач? bitmap или обычный не уникальный индекс b-tree?

Кроме того, какой индекс может улучшить запрос для двоичного столбца (NUMBER(1,0) с yes/no значениями)?

Отказ от ответственности: Я случайный dba.

+1

В вашем случае предпочтительнее «растровый индекс». Вы сказали: «... 99,9% строк с полным ...», если вы ОБНОВЛЯете Task.ProcessState только с одного сеанса, у вас не будет никакого влияния на производительность, иначе сеансы должны будут сериализовать его доступ к индексу. –

+1

Каков запрос, который вы пытаетесь улучшить? –

+0

@a_horse_with_no_name Нравится это: 'select task_id from task, где processstate = 0' (ожидается только <500 строк). – mshsayem

ответ

1

Я предполагаю, что вас интересует выбор строк с состояниями (Queued/Running) для их обновления. Так что было бы хорошо отделить завершенных строк от других, потому что нет большого смысла в индексировании завершенных строк. Вы можете использовать пассификацию здесь или функциональный индекс с функцией, возвращающей NULL для завершенных строк и фактических значений для остальных, в этом случае в дереве индексов появляются только незавершенные строки.

1

Правильный (b * дерево) индекс в порядке. Просто убедитесь, что в столбце есть гистограмма. (См. Параметр METHOD_OPT в DBMS_STATS.GATHER_TABLE_STATS).

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

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

Кроме того, что индекс может улучшить запрос для двоичного столбца (NUMBER (1,0) с только да/нет значений)

К сожалению - я пропустил эту часть вашего вопроса. Если данные в столбце перекошены (т. Е. Почти все 1 или почти все 0), то регулярный (b * tree) индекс, как указано выше. Если данные распределены равномерно, то ни один индекс не поможет. Чтение 50% строк таблицы по индексу будет медленнее, чем полное сканирование таблицы.

+0

* Обычный (b-tree) индекс является хорошим * - это не так, чтобы включить растущие строки полного состояния, установленные в индекс. Единственный подходящий метод для создания полных записей состояния, установленных в * общем случае *, - это FTS. Таким образом, мы получаем накладные расходы на обслуживание индекса без каких-либо выигрышей.Поэтому IMHO приятно индексировать только незавершенные строки состояния. –

+0

Я попытался сохранить свой ответ простым; используя предоставленную информацию. Это звучит для меня так же, как OP был вовлечен в роль DBA и пытается улучшить производительность существующего приложения. Индексы, основанные на функциях, могут использоваться для пропуска «завершенных» записей, но тогда вам нужно изменить запросы приложений на использование той же функции, иначе вы не получите никакой выгоды. Я не предполагал, что у него есть время, полномочия и т. Д., Чтобы внести такие изменения. В таблице, которую он описал, и о целях запроса, которые ему заданы, индекс дерева b * на ProcessState будет быстрым и эффективным решением, даже если он действительно теряет некоторое пространство –

 Смежные вопросы

  • Нет связанных вопросов^_^