一般に、RACを使用していない場合は、逆キーインデックスを使用する理由はありません。
パフォーマンスの観点からは、挿入の対象となる任意の時点で1つまたは2つのホットブロックを使用する方がはるかに優れています。これは、ホットブロックがバッファキャッシュとINSERT ディスクからブロックを読み取るコストを負担する必要はありません。インデックス内のランダムなブロックに挿入される場合、必要なブロックがキャッシュから古くなり、物理I/Oのコストが発生する可能性がはるかに高くなります。
インデックスのバランスを保つためのコストはごくわずかですが、それでも標準のインデックスを優先します。通常のインデックスでシーケンス生成された主キーがある場合、Oracleは90/10ブロック分割 そのブロックがいっぱいになると、右端のブロックに表示されます。対照的に、逆キーインデックスがある場合、Oracleは50/50ブロック分割 特定のブロックがいっぱいになるたびに。 50/50ブロック分割は、古いブロックから新しいブロックにデータの半分をコピーし、90/10ブロック分割は、右端のデータ値のみを新しいブロックにコピーします。したがって、90/10ブロック分割は、50/50ブロック分割よりもはるかに安価であり、選択するインデックスのタイプに関係なく、ほぼ同じ数のブロック分割を実行する必要があります。したがって、通常のインデックスを維持するコストは、キャッシュの影響を無視しても、リバースキーインデックスを維持するコストよりも低くなります。
リバースキーインデックスの使用を検討する理由は、RACを使用していて、多くのRACノードがすべて同じホットブロック上で競合するコストを回避したいためです。次の挿入を行うために、あるノードから別のノードにホットブロックを常に送信する必要がある場合は、その競合を減らすために、代わりに逆キーインデックスを使用する価値があります。パーティショニングオプションのライセンスを取得している場合は、代わりにハッシュパーティションインデックスを使用することをお勧めします（これは、テーブルがパーティション化されているかどうかに関係なく実行できます）。パーティショニングオプションのライセンスを取得していない場合は、ホットブロックでの競合を解決するのにリバースキーインデックスで十分であり、パーティショニングのライセンスを取得する必要がない場合があります。