tky(e@TKrE816> select 90101, dump(reverse(90101),16) from dual

2 union all

3 select 90102, dump(reverse(90102),16) from dual

4 union all

5 select 90103, dump(reverse(90103),16) from dual

90101 DUMP(REVERSE(90101),1

90101 Typ=2 Len=4: 2,2,a,c3

90102 Typ=2 Len=4: 3,2,a,c3

90103 Typ=2 Len=4: 4,2,a,c3

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

where x> 5

Данные в индексе не отсортированы, поэтому просмотреть диапазон нельзя. С другой стороны, некоторые просмотры диапазонов в индексе с обращенным ключом вполне выполнимы. Если имеется составной индекс по столбцам X, Y, при поиске по следующему условию можно будет использовать индекс с обращенным ключом и просматривать диапазон в нем:

where x = 5

Дело в том, что байты в столбце X обращены, и байты в столбце Y тоже обращены. Сервер Oracle не обращает байты значения X Y, а сохраняет в записи индекса резуль-выполнения reverse(X) reverse(Y). Это означает, что все значения X = 5 будут храниться вместе, так что сервер Oracle может просматривать последовательно листовые блоки индекса для поиска всех таких строк.

Индексы по убыванию

Индексы по убыванию - новое средство сервера Oracle 8i, расширяющее функциональные возможности индекса на основе В*-дерева. Они позволяют хранить значения столбца в индексе от большего к меньшему , а не по возрастанию. Прежние версии сервера Oracle всегда поддерживали ключевое слово DESC (по убыванию), но при этом игнорировали его - оно не влияло на хранение и использование данных в индексе. В версии Oracle 8i, однако, это ключевое слово изменяет способ создания и использования индексов.

Сервер Oracle давно может просматривать индексы в обратном порядке, поэтому кажется странным, зачем такая возможность вообще понадобилась. Например, если использовать таблицу Т из предыдущего примера и выполнить следующий запрос:

tkyte@TK:E816> select owner, object type 2 from t

3 where owner between T and Z

4 and object type is not null

5 order by owmer DESC, object type DESC

46 rows selected. Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=46 Bytes=644)

1 0 INDEX (RANGE SCAN DESCENDING) OF T IDX (NON-UNIQUE) . . .

Оказывается, что сервер Oracle будет просто читать индекс в обратном порядке, поскольку в этом плане выполнения нет завершающей сортировки - данные и так отсортированы. Возможность создавать индекс по убыванию имеет значение только для составного индекса, в котором некоторые столбцы упорядочены по возрастанию (ASC), а некоторые - по убыванию (DESC). Например:

tkyte@TKYTE816> select owner, object type

2 from t

3 where owner between T and Z

4 and object type is not null

5 order by owner DESC, object type ASC

46 rows selected. Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=46 Bytes=644)

1 0 SORT (ORDER BY) (Cost=4 Card=46 Bytes=644)

2 1 INDEX (RANGE SCAN) OF T IDX (NON-UNIQUE) (Cost=2 Card=

Сервер Oracle больше не может использовать имеющийся индекс по столбцам (OWNER, OBJECT TYPE, OBJECT NAME) для сортировки данных. Он мог бы читать его в обратном порядке для получения данных, отсортированных по критерию OWNER DESC, но ему надо читать их по возрастанию, чтобы получить отсортированные по возрастанию данные в столбце OBJECTTYPE. Поэтому по индексу в1бирают-ся все строки, а затем сортируются. Здесь поможет индекс с ключевым словом DESC:

tkyte@TKYTE816> create index desc t idx on t(owner DESC, objecttype ASC)

2 / Index created.

tkyte@TKYIE816> select owner, object type

2 from t

3 where owner between T and Z

4 and object type is not null

5 order by owner DESC, object type ASC

46 rows selected.

Execution Plan

Индексе! 3 5 1

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=46 Bytes=644)

1 0 INDEX (RANGE SCAN) OF DESC T IDX (NON-UNIQUE)...

Теперь опять можно читать отсортированные данные - дополнительного шага сортировки в конце плана нет. Учтите, что если параметр COMPATIBLE в файле init.ora не имеет значения 8.1.0 или выше, опция DESC в операторе CREATE INDEX будет проигнорирована: никаких предупреждений или сообщений об ошибке выдано не будет, поскольку это - стандартное поведение для прежних версий сервера.

Когда имеет смысл использовать индекс на основе В*-дерева?

Не слишком веря в простые правила (из каждого правила есть исключения), я не использую никаких простых правил для определения того, когда использовать (или не использовать) индекс на основе В*-дерева. Чтобы обосновать свою точку зрения, я представлю два одинаково верных правила:

используйте индексы на основе В*-дерева по столбцу, если предполагается выбирать из таблицы по индексу лишь небольшую часть строк;

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

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

Как средство доступа к строкам в таблице. Индекс читается, чтобы добраться до строки в таблице. Так имеет смысл обращаться к очень небольшой части строк таблицы.

Как средство ответа на запрос. Индекс содержит достаточно информации, чтобы дать полный ответ на запрос - к таблице вообще не придется обращаться. Индекс будет использоваться как уменьшенная версия таблицы.

Первое правило относится к случаю, когда имеется таблица Т (используем таблицу Т из предыдущего примера) и применяется следующий план выполнения запроса:

tkyte@TKYTE816> set autotrace traceonly explain

tkyte@TKYTE816> select owner, status

2 from T

3 where owmer = USER;

Execution Flan

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 TABLE ACCESS (BY INDEX ROWID) OF T

2 1 INDEX (RANGE SCAN) OF T IDX (NON-UNIQUE)