时隔4年，重新分析并修正一个update SQL的优化方法

最近在整理一些SQL改写方面的案例，发现2014年底做的一个优化项目，里面有一个update SQL的改写不是太严谨（对业务来说应该也没有什么影响，因为涉及到改写，也不知道开发人员最终有没有接受这个改写）。今天这篇文章对那个改写做了修正，上万倍的性能提升还是非常值得开发做这个改动。

对于SQL改写来说，改写前后的等价性非常重要，有时你看到的是当前数据情况下的结果集相同，如果换了不同的数据，或者考虑一些极端情况，可能就不相同了。通过比较结果集来判断等价性还不够，最好是有理论依据。网上常见的in/exists改表关联的错误改写，我在之前的某篇文章就纠正过。

某些SQL的写法本身就注定了效率是非常低的，我见过一些标量子查询的SQL，主查询返回较大大结果集，导致SQL执行时间非常长，而且开发人员还使用了较大的并行试图加快速度，殊不知即使加到几百的并行度，也于事无补，这种SQL不但慢，还消耗大量的系统资源，只能改写才能解决。改写后可以从原来的几个小时，缩短到几秒钟。Oracle数据库非常强大，可以接受各种各样的写法，但是如果不按照它的最佳实践来使用，也很难发挥出它应有的效果。

下面这个SQL还好，如果应用还未上线，可以建议按照下面介绍的方法改写一下。如果是生产系统，还有一种优化方法，虽然效率比改写稍微差了那么一点点，还是非常值得操作的，你想到了吗？想到的可留言。

为了能够比较清楚的显示分析过程，文章使用了PPT截图。

内容如有不当之处，敬请指正，感激不尽！

（完）