SQL优化三板斧：精简之道、驱动为王、集合为本(3)

那么问题出在哪里呢?没的说,肯定是执行计划并没有按我们预想的去执行这个SQL.此时,我也没有心思去仔细分析执行计划,而是直接祭出了第三板斧通过with子查询的方式将ORDER_REL、SHP、REL三个子查询封装成结果集,改写后的SQL如下：

再看执行计划：

看起来与我们预期的效果一致了,而关键还是要看执行的效率.

3.5S,也不到10s皇天不负有心人,终于可以画“句号”了.此时,已经是第三天上午,距离拿到原始SQL将近2天的时间了.台风“妮妲”早已销声匿迹,来也匆匆去也匆匆.你方唱罢我登场,立秋前的烧烤模式再次以胜利者的姿态,歇斯底里的“蒸烤”着这片大地.而躲在空调房的人类,也在尽情的透支着地球赐予的有限资源,最终会如同这个SQL一样,终有一天会引发灾难；而再去治理,再去挽救,需要花费更多的资源与精力.

后记

从4分钟到3.5S,从钻取卡顿到一泻千里,整整经历了近2天时间,耗时之长在以往的优化案例中实属少见.事实上,当一开始拿到这个SQL时,尤其是在了解到这个SQL及背后的数据环境时,我心里面是直打鼓的.可以说,是硬着头皮拿下了这个SQL,现在回想起来仍然后怕.然而,除了后怕,更多的是该案例优化过程中所体现出的SQL(优化)精髓：精简之道、驱动为王、集合为本.

精简之道

大道至简、简单即高效、复杂的事情简单化等等这些我们喜闻乐见的生活常识,同样适用于SQL(优化).记得SQL优化大师曾说过：不要让ORACLE做多余的事.而对于ORACLE而言,多余的事情是什么呢?多余的表关联、重复的表访问、冗余的关联(过滤)条件、不必要的DISTINCT\ORDERBY\GROUPBY、曲折的访问路径.虽然ORACLE优化器引擎也在努力识别并消除这些“多余的事”(可参见博客,然而,在面对复杂的SQL时,ORACLE也往往束手无策.因此,SQL优化的首要之事就是精简SQL.

驱动为王

有这样一句话：一头狮子领着一群羊,要胜过一头羊领着一群狮子.这就道出了“领头”的重要性,在ORACLE优化器中,就是“驱动表”.驱动表的意义有如木楔子,只有薄如纸片锐如刀刃的楔子,才能轻而易举的插入坚硬木桩中.如果给你一个圆头的木头,任凭你力气再大,也不能插入.这就要求驱动表的数据量要足够的少.尽管ORACLE优化器也在努力寻找合适的“领头”,而有的时候,ORACLE优化器会被腰里别了杆枪的老鼠给骗了.比如本案例中的A类子查询,起初是通过IN子查询进行过滤的,这就存在很大的性能风险.关于驱动表的优化案例有很多,后续会专题分享.

集合为本

集合操作是二维关系数据库引擎在数据处理时的根本,单表是一个集合,多表关联后的结果也是一个集合,视图、子查询的返回结果还是一个集合,整个SQL执行完后的结果仍然是一个集合.

因此,一个高效的SQL一定有一个合理的集合运算结构.根据业务需求,结合代码逻辑,有的时候需要将代码片通过子查询封装；而有的时候又需要将子查询合并到主查询中；有的时候需要将大集合根据业务逻辑切片成多个小的集合；有的时候又需要将若干个小的集合预先合并成大集合.总之,在进行SQL(优化)时,一定要有集合的概念,用集合的思维指导SQL(优化).

文章出处：DBAplu社群(订阅号ID:dbaplus)

（编辑：ASP站长网）