0

workitem_routing_stats テーブルには約 1000000 のレコードがあります。すべてのレコードがアクセスされるため、フル スキャン ヒントを使用しています。このクエリを調整する方法があれば、実行に約 25 秒かかります。

SELECT /*+ full(wrs) */
wrs.NODE_ID,
wrs.bb_id--,
SUM(CASE WHEN WRS.START_TS >= (SYSTIMESTAMP-NUMTODSINTERVAL(7,'day'))
AND wrs.END_TS <= SYSTIMESTAMP THEN (wrs.WORKITEM_COUNT) END) outliers_last_sevend,

SUM(CASE WHEN WRS.START_TS >= (SYSTIMESTAMP-NUMTODSINTERVAL(30,'day'))
AND wrs.END_TS <= SYSTIMESTAMP THEN (wrs.WORKITEM_COUNT) END)
outliers_last_thirtyd ,

SUM(CASE WHEN WRS.START_TS >= (SYSTIMESTAMP-NUMTODSINTERVAL(90,'day'))
AND wrs.END_TS <= SYSTIMESTAMP THEN (wrs.WORKITEM_COUNT) END)
outliers_last_ninetyd ,
SUM(wrs.WORKITEM_COUNT)outliers_year

FROM workitem_routing_stats wrs
WHERE wrs.START_TS BETWEEN (SYSTIMESTAMP-numtodsinterval(365,'day')) AND SYSTIMESTAMP
AND wrs.END_TS BETWEEN (SYSTIMESTAMP-numtodsinterval(365,'day')) AND SYSTIMESTAMP
GROUP BY wrs.NODE_ID,wrs.bb_id ;
4

3 に答える 3

1

START_TS 列で月単位でテーブルをレンジ パーティション化できます。（関心のある年のみをスキャンします）

2 番目に (非常にインテリジェントなソリューションではありません)、ストレージが強力な場合は、parallel(wrs 4) ヒントを追加できます。

この2つを組み合わせることができます。

于 2012-09-05T13:17:40.973 に答える
0

いずれにせよ、フルスキャンは苦痛になるでしょう...

ただし、変換関数を呼び出す代わりに適切な数値を入力するだけで、計算を回避できます。

(SYSTIMESTAMP-numtodsinterval(365,'day'))

ちょうど同じでなければなりません

(SYSTIMESTAMP-365)

これにより、関数の呼び出しとパラメーター文字列 ('day') の解析のオーバーヘッドが取り除かれます。

于 2012-09-05T12:37:14.253 に答える
0

もう1つの可能性 - おそらくこのデータは今日の時点で新しいタイムスタンプを追加するようですが、残りは単なる歴史です...

この場合、要約された履歴情報を保持する要約テーブルを追加し、最近のものについてはこの現在のテーブルのみをクエリし、古いものについては要約テーブルに UNION をクエリすることができます。

次に、JOB またはその他のスケジュールされたプロセスを検討して集計を取得する必要がありますが、このクエリ時間を大幅に節約できます。

于 2012-09-05T14:11:59.930 に答える