昂貴的甲骨文窗函數

我使用的窗函數來計算的序列號：昂貴的甲骨文窗函數

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

記錄表對ABC_ID唯一索引和ENCOUNTER_ID非唯一索引。

的MEASURE表對ABC_ID和LINE的唯一索引（在查詢不使用）。

的解釋查詢計劃沒有ROW_NUMBER（）給出了以下幾點：在與ROW_NUMBER（）查詢

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

解釋計劃給出了以下幾點：

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

似乎交叉表索引將有助於（在R.ENCOUNTER_ID和M.MEASURE_ID上），但我不確定它是否受支持。

我不知道該表統計信息更新頻率。

有沒有辦法在我的窗口函數上獲得更好的性能？每張桌子能否從額外的指數中受益？

來源

2012-05-31 craig

這可能已經優化了幕後，或可能不會幫助，但我不認爲你需要'R.ENCOUNTER_ID'和'M.MEASURE_ID'在'ORDER BY'，因爲他們在已經很'PARTITION BY'。在每個分區中，每列中的值將全部相同。 –

哈希後的成本高，加入意味着你的哈希聯接溢出到磁盤，因爲它通常增加了一個可以忽略不計的成本。使用DBMS_Xplan獲取所需的臨時空間的估計值。

如果你的內存限制在哈希聯接則窗口功能也將會從內存不足的困擾。監視v $ sql_workarea以查看是否有多次排序，並考慮在此查詢期間增加內存分配。

至於索引，我懷疑有什麼可以做。

來源

2012-05-31 19:35:00

昂貴的甲骨文窗函數

回答

相關問題