3

Oracle での経験に基づいて、DATE 型の列に設定するインデックスの最適な型と設定は何ですか?

  • 必ずしもパーティション分割されたインデックスを使用する必要はありません。
  • これは、ログの種類のテーブルです。
  • 主キーとして一意のIDを気にする必要はありません（実際、ほとんどの場合、日付は一意になるのに十分近いですが、その性質上、一意になることはありません）。

クラスタ インデックスを作成するのは公平でしょうか?

私が興味を持っているのは、SELECT * FROM Log WHERE [Date] > '20-06-2009' ORDER BY [Date] DESC のようなクエリの実行を最適化し、挿入を大幅に遅くしないことです。(ところで、現実の世界では、切り捨てやインデックスの欠落を避けるために、正しい TO_DATE 構文を使用します)

乾杯、

4

3 に答える 3

7

通常のインデックスはうまくいくはずです。これはログであるため、新しいエントリは常に増加する日付値を持つ必要があり、過去の日付であってはなりません。これにより、インデックスの追加が容易になります。挿入の大きな減速ではありません。

上記で問題が発生した場合にのみ、より複雑なインデックスを検討してください。

よろしくK

于 2009-06-11T08:41:21.383 に答える
5

通常の B ツリー インデックスが適切ですが、これが日付の値が増加するログ テーブルである場合は、インデックス ブロックの競合に注意してください。新しい値をインデックスに挿入する多くのセッションがあり、それらの値が同じブロックに属している場合、パフォーマンスの問題が発生する可能性があります。これに対する緩和策の 1 つは逆キー インデックスですが、逆キー インデックスは範囲スキャンをサポートできないため、指定したタイプのクエリのコストが高くなります。代わりに、フル インデックス スキャンまたは高速フル インデックス スキャンを取得します。

また、インデックス ブロックの分割が 50/50 になるため、インデックスが大きくなります。これは、Oracle がインデックス付きの値で右方向の増加パターンを検出したときに使用する 90/10 ではなく、50/50 になるためです。

于 2009-06-11T17:36:59.953 に答える
1

データの量に応じて、パーティション化を再検討します。Oracleはクエリの実行時にパーティションプルーニングを使用できます。これには、後で古いログデータを簡単にアーカイブできるという利点もあります。

于 2009-06-16T04:42:59.147 に答える