一波三折的优化案例

在经过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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/693533/viewspace-1983402/