Хорошая практика использования обратных индексов на суррогатных ключах? (Оракул)

скажем у меня есть таблица с автоинкрементным суррогатный ключ.

будет ли это хорошим случаем для использования обратного индекса?

правильно ли я говорю:

вставки (в индекс) будут быстрее .. поскольку новые значения будут вставляться случайным образом, вместо того, чтобы всегда идти вправо больше листа (постоянно заставляя перебалансировки).

Поиск индекса будет немного медленнее .. поскольку БД пришлось бы потратить (немного) времени на обращение вспять индекс.

Так как это суррогатный ключ .. Мне действительно не нужна способность сканирования диапазона (что вы не можете сделать с обратными индексами).

(обратите внимание, я не использую Oracle RAC)

1 ответов


В общем случае, если вы не используете RAC, не было бы причин использовать индекс обратного ключа.

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

стоимость поддержания сбалансированного индекса довольно минимальна, но даже это благоприятствует стандартному индексу. Если у вас есть сгенерированный первичный ключ последовательности с нормальным индексом, Oracle сделает 90/10 block split справа-самый блок, когда этот блок заполняется. Напротив, если у вас есть индекс обратного ключа, Oracle должен сделать 50/50 блок splits, когда данный блок заполняется. Разделенный блок 50/50 копирует половину данных из старого блока в новый блок, разделенный блок 90/10 копирует только самое правильное значение данных в новый блок. Таким образом, разделение блоков 90/10 намного дешевле, чем разделение блоков 50/50, и вам нужно будет сделать примерно одинаковое количество разбиений блоков независимо от типа индекса, который вы выбираете. Таким образом, стоимость поддержания регулярного индекса меньше, чем стоимость поддержания индекса обратного ключа, даже игнорируя эффект кэша.

причина, по которой вы рассматриваете использование индекса обратного ключа, заключается в том, что вы используете RAC, и вы хотите избежать стоимости наличия многих узлов RAC, сражающихся за один и тот же горячий блок. Если вам постоянно приходится отправлять горячий блок с одного узла на другой, чтобы сделать следующую вставку, может быть, стоит использовать индекс обратного ключа вместо этого, чтобы уменьшить это утверждение. Если вы лицензировали опцию секционирования, было бы лучше использовать секционированный хэш вместо этого индексируйте (это можно сделать независимо от того, секционированы ли таблицы). Если вы не лицензировали опцию секционирования, индекс обратного ключа может быть достаточно хорош для разрешения разногласий в горячем блоке, чтобы не требовать лицензирования секционирования.