ITPub博客

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

一波三折的优化案例

原创 Oracle 作者:juan025 时间:2019-02-17 14:21:05 0 删除 编辑

在经过2个小时的讲解和确认后,我对这个SQL进行了改写,其实也说不上改写,因为我就是在SQL的最开头将根据业务规则,找到这个XM_RWJH相关的XM_RWJH用with封装起来,并在SQL语句中,将该结果集作为驱动表,完成整个数据提取。将这个SQL在数据库里面执行,飞快,不到2秒。

 

第三次优化:改写,将exists改成join

大概也就过了一周的时间,收到了一封陌生人发过来的熟悉的邮件,说是陌生人是因为显示的发件人我不认识,说熟悉是因为邮件的title是“待办事项SQL语句超时,请帮忙优化”,天杀的待办SQL,怎么又出问题了?我打开邮件,发现正文中的SQL并不是我上次优化的SQL,因为很明显没有with子句。什么情况?上次的优化SQL被覆盖了?开发人员异动了?各种乱糟糟的,看来邮件已经无法承载如此复杂的沟通内容了,我决定直接找发件人一探究竟。

在于开发人员进行沟通后,澄清了我的疑问:

1、  之前的开发人员确实是离职了,她是来接替工作了;

2、  之前的优化SQL并没有被覆盖,因为这是另外一种场景下的待办事项

天呐,我一周前还在庆幸开发人员的稳定性为性能优化带来的好处,突然间就被黑脸了。而且,接手的开发人员对业务逻辑根本不清楚,今天出现这个问题,是测试人员提出来的:操作超时。没有办法,我只能耐着性子,与这位新的开发人员一起梳理。

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

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

注册时间:2019-02-13

  • 博文量
    26
  • 访问量
    20474