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。 最后又做了分析，发现 罪魁祸首的 统计信息。  我居然第一天优化的时候 发现过时了， 竟然没有收集！！ 而且都意识到了。

哎， 我们业务上面大量的 删， 添 数据发生在白天， 而系统 收集确实在晚上。 这个需要 有个策略好好 保证统计信息准确的  。

我以后 一定会注意统计信息  导致的问题的 ，   依此谨记！！！！！