今天思前想后还是把一次失败的优化 经历写下来吧, 防止以后再犯同样的错误。 以后谨记教训。
哎, 其实还差一点就到达我想要的效果了。
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 没有!!!!
也就是找的时间+ 回滚段的时间 而且还没有意义, 所以加上条件后 变成了 1S 了...