Oracle 10g: почему Oracle выполняет полное сканирование таблицы вместо использования индекса B-дерева с низкой мощностью в этом случае?

Question

Я исследую индексы в Oracle 10g, чтобы ускорить конкретный запрос. Снова и снова я читаю, что индексация столбцов с низким числом элементов (столбцы с очень небольшим количеством уникальных значений, например, столбец пола в таблице сотрудников) очень редко помогает ускорить поиск. Это имеет смысл, если данные в этом столбце с низким количеством элементов распределены равномерно, например, ~50% записей о сотрудниках имеют пол = 'M', а остальные ~50% имеют пол = 'F'. Но что делать, если данные распределены неравномерно, и вы ищете записи, которые не имеют того же ключа, что и большинство? Что, если вышеприведенный столбец по полу был проиндексирован, таблица сотрудников была предназначена для компании, в которой работали 2% мужчин и 98% женщин, и мы только каждый из них выполняем запросы по сотрудникам мужского пола. Это эмпирическое правило с низким уровнем мощности все еще остается в силе?

Ситуация, с которой я сейчас имею дело, - это таблица, в которой есть ненулевой двоичный столбец, в каждой записи всегда хранится либо 1, либо 0. В этой таблице есть что-то вроде 99999 записей с 0 и одна запись, в которой хранится 1. Oracle выбирает полное сканирование таблицы, когда у меня есть двоичный индекс для этого двоичного столбца.

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

Answer 1

Дэн,

И ответ кроется в вопросе ниже. Какие существуют типы / типы индексов в Oracle (например)?

Когда есть столбцы с большей избыточностью (Low Cardinality), Bitmap Indexes - лучший выбор.

Например, предположим, что таблица с именем столбца Employee_status. Значения (YES | NO). Выберите * из emp, где Employee_Status='Regular';

Если у вас есть B-Tree Index, Hash index ... кроме Bitmap Index, это очень поможет, несмотря на использование фильтров и индексов.

Спасибо Прашант Диксит www.oracleant.com