Wenn Sie RAC nicht verwenden, gibt es im Allgemeinen keinen Grund, einen Reverse-Key-Index zu verwenden.
Vom Leistungsstandpunkt aus sind Sie viel besser dran, wenn Sie zu einem bestimmten Zeitpunkt ein oder zwei Hot Blocks haben, die Einfügungen unterliegen, da dies im Wesentlichen garantiert, dass sich die Hot Blocks im Puffercache und im INSERT müssen nicht die Kosten für das Lesen des Blocks von der Festplatte tragen. Wenn Sie Einfügungen in zufällige Blöcke in einem Index haben, ist die Wahrscheinlichkeit viel größer, dass der gewünschte Block aus dem Cache gealtert ist und die Kosten eines physischen I/O verursachen würde.
Die Kosten für die Aufrechterhaltung eines ausgeglichenen Indexes sind ziemlich gering, aber selbst das spricht für einen Standardindex. Wenn Sie einen sequenzgenerierten Primärschlüssel mit einem normalen Index haben, führt Oracle einen 90/10-Blockaufteilung auf dem Block ganz rechts, wenn dieser Block voll ist. Wenn Sie dagegen einen Reverse-Key-Index haben, muss Oracle 50/50-Blockaufteilung immer wenn ein bestimmter Block voll ist. Eine 50/50-Blockteilung kopiert die Hälfte der Daten aus dem alten Block in den neuen Block, eine 90/10-Blockteilung kopiert nur den Datenwert ganz rechts in den neuen Block. Der 90/10-Blocksplit ist daher viel billiger als ein 50/50-Blocksplit und Sie müssten ungefähr die gleiche Anzahl von Blocksplits durchführen, unabhängig von der Art des Index, den Sie auswählen. Die Kosten für die Verwaltung eines regulären Index sind also geringer als die Kosten für die Verwaltung eines Reverse-Key-Index, selbst wenn die Auswirkungen des Cache ignoriert werden.
Der Grund, warum Sie die Verwendung eines umgekehrten Schlüsselindex in Betracht ziehen würden, wäre, dass Sie RAC verwenden und die Kosten vermeiden möchten, dass viele RAC-Knoten alle um denselben heißen Block kämpfen. Wenn Sie den heißen Block ständig von einem Knoten zum anderen transportieren müssen, um die nächste Einfügung vorzunehmen, kann es sich lohnen, stattdessen einen umgekehrten Schlüsselindex zu verwenden, um diesen Konflikt zu reduzieren. Wenn Sie die Partitionierungsoption lizenziert haben, wäre es noch besser, stattdessen einen Hash-partitionierten Index zu verwenden (dies kann unabhängig davon erfolgen, ob die Tabellen partitioniert sind oder nicht). Wenn Sie die Partitionierungsoption nicht lizenziert haben, kann ein umgekehrter Schlüsselindex gut genug sein, um Konflikte im Hot Block zu lösen, sodass Sie keine Partitionierungslizenz benötigen.
