0

これは、Oracle で実行されている SQL クエリだと思います。

SELECT ID, DEVICE_TYPE, S3_KEY, TO_CHAR(CREATION_DATE, 'YYYY-MM-DD HH24:MI:SS') AS CREATION_DAT
FROM KASE_DDL.ARCHIVED_LOG 
WHERE 
    CREATION_DATE >= TO_DATE('{DIST_YYYY/MM/DD HH24:MI:SS_UTC}', 'YYYY/MM/DD HH24:MI:SS') 
    AND CREATION_DATE <= TO_DATE('{DIET_YYYY/MM/DD HH24:MI:SS_UTC}', 'YYYY/MM/DD HH24:MI:SS')

実行が遅いので、効率を改善するためにどのように書き直すことができるのでしょうか。たとえば、CREATION_DATE に作成されたインデックスがある場合、このクエリはインデックス作成を利用できますか? 列の周りに計算がある場合、Oracle はその列に構築されたインデックスを使用できない可能性があると本を読んだことを覚えています。私のクエリはこのケースに当てはまりますか? 他の提案はありますか？ありがとうございました。

アップデート：

私の問題では、CREATION_DATE にインデックスが組み込まれています。このクエリでデータベースがインデックスを利用できるようになるかどうかに興味があります。

4

3 に答える 3

2

に索引を追加しますCREATION_DATE。

日付にも演算子を使用しBETWEENますが、そのように読むのが好きです。

于 2012-12-18T17:06:39.220 に答える
0

user_indexesテーブルのclustering_factorを、テーブルの行数およびブロック数と比較することで、インデックスの有効性を確認できます。クラスタリング係数は、ブロック数と行数の間にあり、それぞれ理論上の最小値と最大値を表します。

クラスタリング係数がブロック数に近い場合（つまり、比較的小さい場合）、インデックスが選択される可能性が高くなり、インデックスへのアクセスに基づいてテーブルからブロックを選択するために必要な作業が少なくなります。

インデックスを使用してテーブルにアクセスしたときに見られるパフォーマンスの向上について疑問がある場合は、常に確認する価値があります。

于 2012-12-19T11:38:21.373 に答える
0

パフォーマンスをさらに向上させるために、カバリング インデックスの使用を試すことができます。あなたの場合はあります

create index ndxCovering on KASE_DDL.ARCHIVED_LOG(CREATION_DATE, ID, DEVICE_TYPE, S3_KEY);

データページをシークせずに、インデックスページからのみデータを読み取ることができます。

于 2012-12-19T11:33:39.787 に答える