2012-03-31 17 views
6

私は、自動インクリメントの代理キーを持つテーブルがあります。サロゲートキーで逆インデックスを使用することをお勧めしますか? (Oracle)

逆インデックスを使用するとよいでしょうか?私が述べるに修正

アム:新しい値がランダムに挿入されるので、(インデックスへ)

挿入ではなく、常に(常にリバランスを強制的に)右のほとんどの葉に行くの..速くなります。

インデックスルックアップはわずかに遅くなります.dbはインデックスを逆転させる時間を少し費やす必要があるためです。

これはサロゲートキーなので、逆方向インデックスではできない範囲スキャン機能は本当に必要ありません。

、あなたはRACを使用していない場合は、一般的には

答えて

8

(Iは、Oracle RACを使用していない、注意してください)逆キー索引を使用する理由はありません。

性能面では、ホットブロックがバッファキャッシュに格納されていることと、INSERTが獲得することが基本的に保証されているため、特定の時点で1つまたは2つのホットブロックディスクからブロックを読み込むコストがかかります。インデックス内のランダムブロックにインサートを挿入した場合、必要なブロックがキャッシュから老朽化し、物理I/Oのコストがかかる可能性がはるかに高くなります。

インデックスのバランスを維持するコストは、最小限に抑えられますが、それでも標準インデックスを優先します。通常の索引でシーケンス生成プライマリ・キーを取得している場合、Oracleはブロックがいっぱいになると最も右のブロックに90/10 block splitを実行します。対照的に、逆キー索引を取得している場合、Oracleはブロックがいっぱいになるたびに50/50 block splitsを実行する必要があります。 50/50ブロック分割は、データの半分を古いブロックから新しいブロックにコピーし、90/10ブロック分割は最も右側のデータ値のみを新しいブロックにコピーします。したがって、90/10ブロック分割は、50/50ブロック分割よりもはるかに安価で、選択するインデックスの種類に関係なく、ほぼ同じ数のブロック分割を行う必要があります。したがって、通常のインデックスを維持するコストは、キャッシュの効果を無視しても逆キーインデックスを維持するコストよりも低くなります。

逆キーインデックスの使用を検討する理由は、RACを使用していて、多くのRACノードがすべて同じホットブロックで競合するのを避けるためです。次の挿入を行うために常にホットブロックをあるノードから別のノードに発送しなければならない場合は、逆のキーインデックスを使用してその競合を減らすことは価値があります。パーティション化オプションのライセンスを取得している場合は、代わりにハッシュ・パーティション化インデックスを使用することをお勧めします(これは、テーブルがパーティション化されているかどうかに関係なく実行できます)。パーティション化オプションのライセンスを取得していない場合は、パーティションのライセンスを必要としないようにホットブロックの競合を解決するには、逆キーインデックスで十分です。

+0

実際、私の経験では、逆キー索引はRACでもそれほど素晴らしいものではありません。私の経験では、ハッシュ・パーティション索引(パーティション数はRACノードの数に2以上の最小の数)ではるかに良いということです。逆キー索引が意味をなさない場合は考えられません。ハッシュ・パーティション化された索引は、非パーティション化された表でも使用できます。 –

+0

@マーク - これを組み込むために私の答えを編集しました、ありがとうございます。 –

+0

パーティションオプションのライセンス要件に関する良い点。私たちは環境全体を通してそのオプションを認可しているので、私は常にそのことを考慮しません。 –

関連する問題