今天一哥們發來一條sql說一直不出結果，最後報錯：ORA-01652: 無法通過 128 (在表空間 TEMP 中) 擴充套件 temp 段

select tran_info.*,
       rp.mcc_typ_id,
       urm2.org_no,
       trim(urm2.rate_type) as rate_type,
       (case
         when tran_info.oldSXF < urm2.max_fee_amt then
          '0'
         when tran_info.oldSXF >= urm2.max_fee_amt then
          '1'
         else
          '0'
       end) as iSCap
  from biz_test.T_BIZ_SINGLE_FEE_TEMP tran_info,
       (select mst.*
          from biz_test.T_BIZ_MERC_SCOPE_TEMP mst
         where mst.merc_id not in
               (select merc_id
                  from biz_test.T_BIZ_SPECIAL_MERC bsm
                 where bsm.spec_type = '2'
                   and bsm.is_used = '1')) urm2,
       biz_test.t_mcc rp
 where tran_info.merc_id = urm2.merc_id
   and tran_info.mcc_cd = rp.mcc_cd
 

解釋：執行計劃裡面有笛卡爾積MERGE JOIN CARTESIAN，單看SQL的話，是不可能產生笛卡爾積的,所以這個問題統計資訊不準導致ROWS算成了1（越是小表ROWS越有可能算成1）。優化器則認為其走的正確的笛卡爾積【什麼是正確的笛卡爾積，什麼是錯誤的笛卡爾積？】假設一個表的資料是30w ，被算成了1 走笛卡爾積，那麼結果集就要被放大30w倍，所以導致temp不足報錯也在情理之中

處理方法：

1.加hint，根據表的大小讓其強制走hash 或者 nl

寫hint很容易眼高手低，而且優化器的版本不同hint的格式也有微小的差別 

2.收集統計資訊：系統自帶有，DBA也會做相應的策略總結：

rows算錯的情況在執行計劃中經常存在，大多都是因為rows算小了，一般會引起兩種錯誤的執行計劃rows算成1 錯誤的笛卡爾積，執行計劃裡面笛卡爾積關鍵字和rowsrows算小了本來應該HASH 結果走了NL，這時候邏輯讀會大的很離譜