0

ウィンドウ関数を使用してシーケンス番号を計算しています。

SELECT  R.ENCOUNTER_ID,
        M.MEASURE_ID,
        M.TAKEN_TIME,
        M.VALUE,
        row_number() OVER(PARTITION BY R.ENCOUNTER_ID, M.MEASURE_ID ORDER BY R.ENCOUNTER_ID, M.MEASURE_ID, TAKEN_TIME ASC) AS SEQ

FROM RECORD R 
INNER JOIN MEASURE M ON R.ABC_ID=M.ABC_ID

RECORD テーブルには、ABC_ID に一意のインデックスがあり、ENCOUNTER_ID に一意でないインデックスがあります。

MEASURE テーブルには、ABC_ID と LINE に一意のインデックスがあります (クエリでは使用されません)。

row_number() を使用しないクエリの実行計画では、次の結果が得られます。

HASH JOIN                 119702
TABLE ACCESS RECORD FULL  278
TABLE ACCESS MEASURE FULL 50696

row_number() を使用したクエリの実行計画では、次の結果が得られます。

WINDOW                    377871
HASH JOIN                 119702
TABLE ACCESS RECORD FULL  278
TABLE ACCESS MEASURE FULL 50696

(R.ENCOUNTER_ID と M.MEASURE_ID で) クロステーブル インデックスが役立つようですが、サポートされているかどうかはわかりません。

テーブルの統計が更新される頻度がわかりません。

ウィンドウ関数のパフォーマンスを向上させる方法はありますか? 各テーブルは、追加のインデックスの恩恵を受けることができますか?

4

1 に答える 1

1

ハッシュ結合後のコストが高いということは、ハッシュ結合がディスクにあふれていることを示唆しています。DBMS_Xplan を使用して、必要な一時領域の見積もりを取得します。

ハッシュ結合でメモリに制約がある場合、ウィンドウ関数もメモリ不足に悩まされます。v$sql_workarea を監視して、マルチパス ソートがあるかどうかを確認し、このクエリ中にメモリ割り当てを増やすことを検討してください。

索引付けに関しては、できることがたくさんあるとは思えません。

于 2012-05-31T19:35:00.397 に答える