Хорошая практика использовать обратные индексы для суррогатных ключей? (Oracle) - PullRequest
6 голосов
/ 01 апреля 2012

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

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

Правильно ли я заявляю:

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

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

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

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

1 Ответ

8 голосов
/ 01 апреля 2012

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...