ITPub博客

首页 > 数据库 > Oracle > 一波三折的优化案例

一波三折的优化案例

原创 Oracle 作者:juan025 时间:2019-06-15 15:54:07 0 删除 编辑

第二次优化:业务,先获取rw_bh

得意不能忘形,否则就是被打脸

在上封邮件中,我大肆批判了IDX_TM_RC_PN_BID_BCTYPE_TN_I这个索引,大有“庆父不死,鲁难未已”的决心,而且,还在别人面前显摆:一看就知道是这个索引的问题。

也就在我这有点飘飘然的时候,第三天,又收到了监控邮件,又是这个SQL,这次虽然未超时,但是超过了30秒,已经触发了优化红线。想起上封邮件中说的“不使用IDX_TM_RC_PN_BID_BCTYPE_TN_I索引,可以将性能提升到10秒左右”,虽然当时正值深圳历史最低气温,脸上仍然是唰唰的红彤彤热乎乎。

望着窗外的寒风冷雨,尽量让燥热的自己冷却下来。既然经验被无情的打败,那只能耐着性子从零开始,重新审视这个SQL及其执行计划。上面提到过,这是一个头轻脚重型的SQL,按道理,这个SQL的执行计划应该不复杂,但是重新审视这个执行计划,却扭扭捏捏72行,这说明在where条件中存在着大量的子查询。果不其然,在执行计划中显示了一个比较大的filter,而在这个filter里面出现了两个引人注意的地方:

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/693533/viewspace-1983398/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2019-02-13

  • 博文量
    26
  • 访问量
    20531