Oracle 異構數據無鍵合併方案：ROWNUM 虛擬列配對百萬行數據的性能陷阱與優化思路

問題場景

兩個無任何共同屬性的數據源 (平面文件/表)，需按行順序一一配對合併。常見方案：為每個來源生成 ROWNUM 作為虛擬鍵關聯。

ROWNUM 配對 SQL

SELECT *
FROM (SELECT a.*, ROWNUM AS rn_a FROM Table_A a) A
JOIN (SELECT b.*, ROWNUM AS rn_b FROM Table_B b) B
  ON A.rn_a = B.rn_b;

百萬行實測：理想 vs 現實

測試數據：Table_A (1~1,000,000)、Table_B (1,000,001~2,000,000)。理想配對應為 (1,1000001)、(2,1000002)…

實際結果 (截圖對比)

• 理想順序：ROWNUM 完美遞增，配對精準。
• 實際順序：Table_A 第 1321 行 ROWNUM=1，Table_B 第 1001321 行 ROWNUM=1 → 錯位配對。

原因：ROWNUM 反映查詢輸出順序，非物理存儲順序。Oracle 讀取塊的順序受 High Water Mark、Free List、並行掃描等影響，不保證與插入順序一致。

性能陷阱

• 百萬行排序生成 ROWNUM 需大量 TEMP 空間與 CPU。
• 並行查詢 (PX) 下每個 Slave 獨立生成 ROWNUM，合併時更亂序。
• 大數據量下 ORDER BY 強制排序更慢，且仍無法保證與另一源同步。

正確替代方案

1. 業務主鍵：務必在源系統設計階段引入全局唯一鍵 (UUID、Sequence、Identity)。
2. ETL 階段打標：抽取時在暫存表按業務邏輯排序生成確定序號 (ROW_NUMBER() OVER (ORDER BY business_key))。
3. 外部表 + 序列：平面文件載入外部表時同步調用 SEQ.NEXTVAL 寫入鍵列。
4. GoldenGate / OGG：異構同步捕獲源端主鍵，目標端按鍵應用。

結論

嚴禁在生產環境依賴 ROWNUM 進行跨源行配對。該方法僅適合臨時分析、數據量小、順序不敏感的探查場景。