インデックス

Question

のすべての列は、我々は3列からなる自然主キーを持つ一時的なデータを格納するテーブルをいくつか持っているオプティマイザ利用します。例：この日の最高温度。これが（この順序で）複合主キーのインデックスです：

id number(10): the id of the timeserie. 
day date: the day for which this data was reported 
kill_at timestamp: the last timestamp before this data was deleted or updated. 

は、ロジックを簡素化：私たちは午前10時に予測を行うと、その後、このID /日の組み合わせが見つかり最後のエントリは彼のcreate_atは9に変更されました：59amであり、新たに計算された値はkill_atタイムスタンプ'31 .12.2999 'で保存されます。このテーブルの上に

典型的なクエリは、次のとおりです。

1) where id=? and day=? and kill_at=? 
2) where id=? and day between (? and ?) and kill_at=? 
3) where id=? and day between (? and ?) 
4) where id=? 

我々は予想していない時系列の多くがあります。つまり、測定されたときに値が1になり、決して変化しないということです。しかし、私たちが200-300回予測するいくつかの時系列データがあります。したがって、1つのid/dayの組み合わせには、kill_atの値が異なる200以上のエントリがあります。

我々は現在、このテーブルの上にのみ（ユニーク）インデックスとして主キー（ID、日、kill_at）を持っています。しかし、クエリ2（正確なIDと日付範囲）でクエリを実行すると、オプティマイザはインデックスの最初の列のみを使用することにします。

ID OPERATION   OPTIONS   OBJECT_NAME OPTIMIZER SEARCH_COLUMNS 
0 SELECT STATEMENT        ALL_ROWS 0 
1 FILTER              0 
2 TABLE ACCESS  BY INDEX ROWID DPD      0 
3 INDEX    RANGE SCAN  DPD_PK     1 

これは、200回以上更新されたタイムシリーズでは本当に痛いです。 これで、オプティマイザがインデックスの3列すべてを使用する方法を探していましたが、ヒントが見つかりません。 1つはありますか？

や私のクエリをスピードアップする方法上の任意の他の提案があるのですか？ピーク期間を短縮しようとします。平均所要時間はあまり重要ではありません。私を混乱させる何

： 上記の実行計画は、私がDBA_HIST_SQL_PLANで見るものです。このステートメントの唯一の実行計画です。しかし、クライアントに説明計画を表示させると、search_columnsの場合は1または3となることがあります。しかし、アプリケーションがこのステートメントを実行するときは、決して3ではありません。

Answer 1

私たちは実際にこの問題の原因を発見しました。私たちはJPA/JDBCを使用しており、JDBCの日付タイプは正しくモデル化されていませんでした。 Oracleの日付型は2番目の精度ではありますが、誰か（私は今彼が嫌いです）は、java.sql.Timestamp型のエンティティの「day」属性を作成しました（時間はなくても1日です）。 これは、タイムスタンプの問合せパラメータと比較する前に、表内の各エントリをタイムスタンプにするためにOracleがキャスト（関数を使用する）する必要があることです。そうすれば、インデックスを適切に使用することはできません。