4

クラスタリング係数 - 計算方法に関する素晴らしい簡単な説明:

基本的に、CF はフル インデックス スキャンを実行し、各インデックス エントリの行 ID を調べることによって計算されます。参照されているテーブル ブロックが前のインデックス エントリのテーブル ブロックと異なる場合、CF はインクリメントされます。参照されているテーブル ブロックが前のインデックス エントリと同じである場合、CF はインクリメントされません。そのため、CF は、テーブル内のデータがインデックス エントリ (常にインデックス エントリの順序で並べ替えられ、格納されている) との関係でどの程度適切に並べられているかを示します。CF が優れている (低い) ほど、インデックスを使用する効率が高くなります。これは、インデックスを介して必要なデータを取得するためにアクセスする必要があるテーブル ブロックが少なくなるためです。

私のインデックス統計:

だから、ここに分析中の私のインデックス（1列だけのインデックス）があります。

インデックスの開始PK_は私の主キーでUIあり、一意のキーです。(もちろん、どちらも一意の値を保持します)

クエリ 1:

SELECT index_name,
  UNIQUENESS,
  clustering_factor,
  num_rows,
  CEIL((clustering_factor/num_rows)*100) AS cluster_pct
FROM all_indexes
WHERE table_name='MYTABLE';

結果：

INDEX_NAME           UNIQUENES CLUSTERING_FACTOR   NUM_ROWS CLUSTER_PCT
-------------------- --------- ----------------- ---------- -----------
PK_TEST              UNIQUE             10009871   10453407          96 --> So High
UITEST01             UNIQUE               853733   10113211           9 --> Very Less

PK の CF が最も高く、他の一意のインデックスはそうではないことがわかります。

私を襲った唯一の論理的な説明は、下のデータが実際には Unique インデックスの列の順序で格納されているということです。

1) この理解で正しいですか?
2) 最小の数値である PK を与える方法はありますCFか?
3) これらの両方のインデックスを使用してクエリのコストを確認すると、単一の選択では非常に高速です。それでも、CF 番号は私たちを困惑させます。

テーブルは 1,000 万レコードを超える比較的巨大で、リアルタイムの挿入/更新も受け取ります。

データベースのバージョンは Exadata X2 上の Oracle 11gR2 です

4

1 に答える 1

5

順序付けられたツリー構造によってインデックス付けされたヒープ テーブルの証拠が見られます。

非常に低い CF 数を取得するには、インデックスに従ってデータを並べ替える必要があります。これを行う場合 (SQL Server や Sybase クラスター化インデックスなど)、Oracle にはいくつかのオプションがあります。

  1. 一般的なクエリを満たすことができる追加の列を持つ補足インデックスを作成するだけです。必要な列がすべて索引に含まれている場合、Oracle は実表を参照せずに索引から結果セットを返すことができます。可能であれば、PK の末尾に列を追加して、最も重いクエリを処理することを検討してください (クエリの列数が少ない場合に実用的です)。これは通常、すべてのテーブルを IOT に変更するよりも推奨されます。
  2. IOT (Index Organized Table) を使用する - これはテーブルであり、インデックスとして保存されるため、主キーによって順序付けられます。
  3. ソートされたハッシュ クラスター - より複雑ですが、特定のキーのレコードのリストにアクセスするときに利益が得られることもあります (特定の電話番号の一連のテキスト メッセージなど)。
  4. データを再編成し、レコードをインデックス順にテーブルに保存します。このオプションは、データが変更されておらず、順序を明示的に制御することはできませんが、ヒープを並べ替えたいだけであれば問題ありません。できることは、クエリを並べ替えて、Oracle に新しいセグメントに追加させることだけです。

アクセス パターンのほとんどがランダム (OLTP) の単一レコード アクセスである場合、クラスタリング要因だけについて心配する必要はありません。これは、悪いことでも良いことでもない単なる指標であり、状況と達成しようとしていることに依存します。

Oracle の問題は SQL Server の問題ではないことを常に覚えておいてください。そのため、設計変更がパフォーマンス測定によって正当化されることを確認してください。Oracle は並行性が高く、競合が非常に少ないです。そのマルチバージョン同時実行設計は非常に効率的で、他のデータベースとは異なります。とはいえ、シーケンシャル アクセスが一般的なユース ケースである場合は、データをシーケンシャル アクセス用に順序付けすることは、依然として優れたチューニング プラクティスです。

この件に関するより良いアドバイスを読むには、Ask Tom: what are oracle's clustered and nonclustered index を読んでください。

于 2014-10-01T19:08:21.757 に答える