ITPub博客

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

一波三折的优化案例

原创 Oracle 作者:juan025 时间:2019-04-23 11:21:07 0 删除 编辑

根据开发人员的表述:这个SQL经过优化后,在功能测试环境是没问题了,但是放在性能测试环境又出现了超时现象。同样的SQL,更好的配置,更差的性能,不用说,这肯定又是数据量导致的。果真,在性能环境主表rp_task_t表的数据量已经达到了5000万,res_cnfg表的数据量也接近5000万,不慢才怪。那么到底是哪个步骤导致了性能慢呢?因为时间充裕,我又回到自己的节奏,先不看执行计划,先看SQL语句,逐行逐行的看:

1、  SELECT部分:没问题,因为都是简单的字段,并没有涉及到函数或子查询;

2、  From部分:通过上次的优化,基本上也没有问题;

3、  Where部分:这部分是没有优化过的,就如第一次优化提到的,这部分是畸形的,而前三次优化都没有涉及到,可见这个疏忽是多么的可怕

最先吸引我的是exists,有没有发现,这个项目对exists特别的情有独钟,感觉如果一个SQL钟没有用exists,好像会显得很寒碜,而一用exists就显得高大上了。这个SQL的exists也一样,除了在第三次优化去掉了两个exists外,在where中还存在三个exists语句,并且存在exists套exists的现象,套也就算了,毕竟有业务要求,但关键是你还套重复了。我们来看下这个exists:

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

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

注册时间:2019-02-13

  • 博文量
    12
  • 访问量
    9410