2016-03-24 15 views
0

パフォーマンスを向上させるために、列に索引を作成する必要があります。列はタイムスタンプ型であり、関数ベースの索引になります。 問題は次のとおりです。この列は頻繁に更新されます。列の索引が頻繁に更新される

Oracleドキュメントでは、頻繁に変更される列の索引付けは行われないと言われています。

この列を照会するより良い方法はありますか?

編集

次のクエリでは、列はVALIDATIONTIMEです:

select * 
from orders 
where VALIDATIONTIME between 
    TO_TIMESTAMP('2016/03/06 10:45:18', 'YYYY/MM/DD HH24:MI:SS') 
and 
    TO_TIMESTAMP('2016/03/15 19:50:18', 'YYYY/MM/DD HH24:MI:SS'); 
+4

インデックスは、パフォーマンス上の問題に役立つ場合にのみ作成する必要があります。トリックは、プロセスのボトルネックを突き止めることです。更新に時間がかかりすぎる場合 - インデックスを作成せず、選択が問題の場合は作成してください。これに続く単一の規則はなく、オラクル社の文書では、これらの場合のベスト・プラクティスのみを推奨しています。 –

+1

上記の人物として、そのトレードオフです。あなたのアプリケーションのためにそれをテストし、最終目標であるものと結果を比較する。 – Dane

答えて

0

タイムスタンプが、それは非常によく、良い選択かもしれので、高いカーディナリティを確保することができますが、それは実際に依存データにアクセスするために使用する述語。 タイムスタンプ列は、行が異なる作業単位で単独で挿入されている場合にのみ良好なカーディナリティを持ちます。 今、私はこのテーブルまたはその使用パターンについて何も知らないが、実際にはデータにアクセスするために使用する述語に依存します。

正確なマイクロ秒で何が起こったかについてはほとんど問いません。だから、形の述語がwhere timestamp_column = some precise valueであることは非常にまれです。 where timestamp_column between :ts1 and :ts2などの範囲式が表示される可能性は非常に高く、その述語にはコンパニオンがあることがよくあります。

だから、総一般化として、あなたが考えることができます:

  • レンジ・パーティションはその日の週のかに囲まれたように、テーブルを定義する複合インデックス
  • の第二またはそれ以降の列としてタイムスタンプ列を配置しますカーディナリティとディストリビューションがそれを正当化するならば、月の開始と終了のタイムスタンプ。または
  • インデックスキーからタイムスタンプをすべて削除し、一意のインデックスで保存することさえできます。

すべては、クエリの特性によって異なります。

関連する問題