性能問題，我的建議query.Please

MERGE INTO Analysis a 
USING (SELECT * FROM Data) b 
ON (a.User_Id = b.User_Id AND a.Upgrade_Flag = 0) 
WHEN MATCHED THEN 
UPDATE SET Status = NVL(a.Status, 'ACTIVATE');

上面的查詢工作fine.But當數以百萬計的記錄都存在，這可能會導致性能issue.Is有以上查詢的任何替代方案，以獲得更好performace.Please建議我對此感謝您的時間性能問題，我的建議query.Please

來源

2011-09-28 user472625

你能向我們展示一份執行計劃嗎？ –

性能調整是證據收集的問題。所以你需要提供更多的信息。兩個表的數據量，數據分佈以及哪些列被編入索引。同時解釋查詢計劃和統計數據。同時指示性的時間，包括你認爲應該是一個合理的時間。最後，背景：這是一項常規工作還是一次性？ – APC

該查詢看起來不錯。也許你應該創建一些索引？

爲Analysis.User_Id創建索引併爲Data.User_Id創建索引（如果尚未創建）（主鍵自動創建索引）。

或者也可能爲包含User_Id和Upgrade_Flag列的Analysis創建索引。

來源

2011-09-28 10:59:07 Juho

Juho：@peter索引已經創建。但是，自從有數萬億條記錄以後，它能否隨時帶來性能問題？ – user472625

沒有看到執行計劃，我無法預測替代方案是否會更有效。但我注意到，您不使用更新中合併源，這表明這可能改寫一個簡單的更新語句：

UPDATE Analysis a 
SET Status = NVL(a.Status, 'ACTIVATE') 
WHERE a.Upgrade_Flag = 0 
AND a.User_Id IN (
    SELECT b.User_Id FROM Data b 
)

由於總是有這些東西的話，你必須使用之間的選擇正如我所示的IN子句或帶有相關子查詢的EXISTS子句。通常，當試圖調整性能時，測試兩個選項都是值得的，但至少在某些情況下，優化器會自行嘗試這種轉換。

來源

2011-09-28 12:03:26

這真的不是很明顯，爲什麼你使用MERGE而不是簡單的更新。

update analysis a 
set a.status = 'ACTIVATE' 
where a.status is null 
and a.upgrade_flag = 0 
and a.user_id in (select b.user_id from data b) 
/

從數據中只選擇USER_ID，而不是整個記錄可以加快速度的，假定DATA.USER_ID索引。

來源

2011-09-28 12:48:38 APC

性能問題，我的建議query.Please

回答

相關問題