Dobra praktyka używania odwrotnych indeksów na kluczach zastępczych? (Oracle)

Question

Powiedz, że mam tabelę z automatycznie zwiększającym się kluczem zastępczym.

Czy byłby to dobry przypadek użycia indeksu odwrotnego?

mam rację, stwierdzając:

wstawienia (język indeksu) będzie szybciej .. ponieważ nowe wartości zostaną wstawione losowo, a nie zawsze idzie w prawo większości liści (stale zmusza przywraca równowagę).

Wyszukiwanie indeksu byłoby nieznacznie wolniejsze, ponieważ db musiałby poświęcić (trochę) czas na cofnięcie indeksu.

Ponieważ jest to klucz zastępczy ... Naprawdę nie potrzebowałbym zdolności skanowania w zakresie zasięgu (której nie można wykonać przy pomocy indeksów wstecz).

(Uwaga, nie używam Oracle RAC)

Answer 1

W ogóle, jeśli nie używasz RAC, nie byłoby żadnego powodu, aby użyć indeksu odwrotnego-key.

Z punktu widzenia wydajności zdecydowanie lepiej jest mieć jeden lub dwa gorące bloki w danym momencie, które podlegają wstawianiu, ponieważ zasadniczo gwarantuje to, że gorące bloki będą znajdować się w buforze podręcznym, a wygrana INSERT Nie musisz ponosić kosztów czytania bloku z dysku. Jeśli masz wkładki trafiające do bloków losowych w indeksie, istnieje znacznie większe prawdopodobieństwo, że żądany blok przestanie działać w pamięci podręcznej i poniesie koszt fizycznego wejścia/wyjścia.

Koszt utrzymania wyrównanego indeksu jest dość minimalny, ale nawet taki, który faworyzuje standardowy indeks. Jeśli masz wygenerowany sekwencyjnie klucz podstawowy z normalnym indeksem, Oracle zrobi 90/10 block split w prawym skrajnym bloku, gdy ten blok się zapełni. W przeciwieństwie do tego, jeśli posiadasz indeks klucza odwrotnego, Oracle musi wykonać 50/50 block splits, gdy dany blok się zapełni. Blok 50/50 podzielił kopie połowy danych ze starego bloku na nowy blok, przy podziale bloku 90/10 kopiuje tylko najbardziej odpowiednią wartość danych do nowego bloku. Rozdzielenie bloku 90/10 jest więc znacznie tańsze niż podział bloków 50/50 i trzeba wykonać mniej więcej taką samą liczbę podziałów bloków, niezależnie od wybranego indeksu. Koszt utrzymania regularnego indeksu jest więc mniejszy niż koszt utrzymania indeksu odwrotnego klucza, nawet ignorując efekt pamięci podręcznej.

Powodem, dla którego warto rozważyć użycie indeksu klucza odwrotnego, jest użycie RAC i uniknięcie kosztów związanych z tym, że wiele węzłów RAC walczy o ten sam gorący blok. Jeśli musisz ciągle wysyłać gorący blok z jednego węzła do drugiego, aby wykonać następną wstawkę, może warto użyć indeksu klucza odwróconego, aby zmniejszyć tę rywalizację. Jeśli masz licencję na partycjonowanie, lepiej byłoby zamiast tego używać skrótu z partycjonowanym indeksem (można tego dokonać, niezależnie od tego, czy tabele są partycjonowane). Jeśli nie masz licencji na opcję partycjonowania, indeks odwrotnego klucza może być wystarczająco dobry przy rozwiązywaniu rywalizacji na gorącym bloku, aby nie wymagać partycjonowania licencji.