SQL優化工作, 不能太激動。記錄失敗的優化經歷，優化從 70分鐘優化到 30秒， 再到1s但還是失敗了

今天思前想後還是把一次失敗的優化 經歷寫下來吧，  防止以後再犯同樣的錯誤。   以後謹記教訓。

哎， 其實還差一點就到達我想要的效果了。

  update   st_mntr_bus_inteorder_oc    a
  set a.unreach = 1
     where arch_flag = 0
       and parent_tache_id = 2017
       and a.create_dt < sysdate - 1 / 12
       and a.create_dt > trunc(sysdate) - 30
       and not exists (select 1
              from st_mntr_zd_order_oc b
             where a.sps_billsn = b.sps_billsn
               and b.local_area_id =  3
               and b.oc_time =66)
       and a.local_area_id = 3
       and a.oc_time =66;     監控中發現這條SQL需要跑 70多分鐘 。 

那我做的第一個工作 就是  試着跑一下，   果真時間很長。   那優化唄....... 

 

然後看了 執行計劃 ， 一看嚇一跳 幾乎所有的表 數據條數都是 1，      自然就走了 filter  操作， 那我想到了統計信息出錯，  然後我試着去查看真實的條數。

一看 大概是  6千條 對  1萬多條。   那沒得說的， 直接用 hint   修改執行計劃， 果真走了hash .  那好試着跑一下唄。  

結果  大振人心， 30S  結果出來了，    (   思路是先找出 rowid 再修改數據   )     ， 看了一下  發現 條件 大坑啊   unreach ！=1 沒有！！！！

， 不加的話， 找出的  unreach =1 的， 並且還修改爲 1的 ， 找要花時間， 並且改成1後 還要 構建   undo 回滾段，   
 也就是找的時間+ 回滾段的時間 而且還沒有意義， 所以加上條件後   變成了 1S 了...

以爲這樣就結束了， 還和友人分析， 結果打錯特錯......  ( 哎太激動了......  )

第二天 一看， 沒有改之前也特莫的 出現3s 爲啥？？    很顯然  走了hash， 爲啥今天走hash 昨天走了 filter？？？  肯定統計信息出問題了，果然一查   晚上2:00 收集的

而第一天的 統計信息  不準確。導致了filter。 最後又做了分析，發現 罪魁禍首的 統計信息。  我居然第一天優化的時候 發現過時了， 竟然沒有收集！！ 而且都意識到了。

哎， 我們業務上面大量的 刪， 添 數據發生在白天， 而系統 收集確實在晚上。 這個需要 有個策略好好 保證統計信息準確的  。

我以後 一定會注意統計信息  導致的問題的 ，   依此謹記！！！！！