0

次のようなOracle 11Gで選択を実行する必要がありました。

select distinct p_date, column1, column2, ...
from table1 t1, table2 t2, ...
where (some join relations)
  and t1.p_date > to_date('010113','ddmmrr')

ある時点で、p_date を介したファイラーによってクエリが非常に遅くなることに気付きましたが、p_date フィルターを使用しない同じクエリはほとんど即時でした。その上、フィルターを使用しないクエリでは、約 30 行という小さな結果セットしか返されないことがわかったので、日付フィルターをクエリの外に移動することを考えました。

私はこれらの2つのオプションを試しました：

with temp as (
select distinct p_date, column1, column2, ...
from table1 t1, table2 t2, ...
where (some join relations)
) select * from temp where p_date > to_date('010113','ddmmrr')

と

select * from (
select distinct p_date, column1, column2, ...
from table1 t1, table2 t2, ...
where (some join relations)
) where p_date > to_date('010113','ddmmrr')

最初にクエリを実行してから、返された 30 行のみに p_date フィルターを適用する必要があるため、内部クエリとほぼ同じ速度であることが期待されます。

ただし、どちらの場合も実行時間は膨大でした (結果が出るのを待つほどの忍耐力がなかったので、どれくらいかかるかはわかりません)。

なぜこれが起こるのか誰か教えてもらえますか？

補足として、テーブル「table1」には、期待どおりに機能していないように見える p_date 上のインデックスがあります（私もそれを処理しています）。しかし、Oracleエンジンがそれを識別し、実行時にクエリを誤って再設計して使用しようとする可能性はありますか?

前もって感謝します、

カルレス

4

1 に答える 1

0

  1. 「いくつかの参加関係」？何か説明...

  2. TEMPをかなり頻繁に利用している明確なキーワードを使用しています。

  3. p_date にインデックスがある場合は、ヒントを使用してみてください: /*+ INDEX */

    select /*+ INDEX (table_name index_name)*/ distinct p_date, column1, column2, ...

    テーブル 1 t1、テーブル 2 t2 から、...

    where (いくつかの参加関係)

    そして t1.p_date > to_date('010113','ddmmrr')

于 2013-06-06T15:36:30.527 に答える