SQL之美 – Oracle 子查询优化系列精讲

：SQL优化及SQL审核，是从泉源处理机能问题的底子手段，无论是开辟人员仍是DBA，都该当持续深切的进修SQL开辟技术，从而为处理机能问题打下根底。

这是我们在一个客户现场碰到的一条SQL机能问题，此SQL子查询成果集前往最多10行，可是整个SQL的机能切欠好，此SQL最初还导致了一个焦点系统毛病，惹起了一个悲剧的工作。

营业反映慢，查询v$session发觉同时有24个回线bsz，因为此SQL机能欠好惹起大量的GC期待，导致其它的营业受影响。

起首申明一下，是OLTP情况。也就认为着要快速的前往成果，而且大都环境下，SQL前往的成果集不多。

在上图SQL中，有两处我们用红色的箭头标识出来。申明这部门消息需要我们关心的。在整个SQL中，就只具有2处过滤消息，一个是redu_owner_id,一个是status_cd。可是status_cd在两个子施行打算中都是不异的，所以这里就只残剩redu_owner_id这列了，我们也能够施行redu_owner_id地点的OP这个表，必定是驱动表，而且redu_owner_id这列该当具有数据倾斜的环境。那么redu_owner_id前往的成果集将间接影响整个SQL机能的黑白。

下面继续查看SQL部门，能够发觉一个主要的消息就是在子查询中具有rownum10,也就意味子查询最多前往10行。在OLTP系统中，具有一个表最初最多前往10行的环境，这里也就大要想到了用子查询做去驱动表了，若是施行打算中，没有用子查询做驱动表，那么很有肯能施行打算就是错误的，那么这里的本人认为的驱动表与之前按照SQL前部门猜测出来当前施行的驱动表（OP）纷歧样。

在施行打算中，我们看到当前施行打算的驱动暗示OFFER_PROD(OP)这个表，与之前我们猜想一样，那么根基能够必定，redu_owner_id列的数据具有倾斜，当前往大量成果集时，机能就很欠好。

在施行打算中，这里特地把子查询标识表记标帜出来，就是需要惹起注重，子查询当着一个全体与主查询做HASH链接，没有作为驱动表走NL，也就能够必定整个施行打算连最根基的驱动表都选择错误。下图能够更直观的看到。

这里做个弥补：子查询看成全体，也就是被看成一个视图与主机做联系关系，什么环境下子查询会看成一个全体呢?

其实MOS有相关的文档申明的，大师能够去MOS一下，在本案例是因为ROWNUM10导致的。

这里看到，具有两个子游标，他们的施行打算相等，可是两个子优化的机能相差很大，而且机能欠好的子优化施行次数良多。

在上面我们提到主查询就只具有两个过滤前提。施行打算+谓词消息能够看到驱动表利用阿谁列来过滤数据。

在上面不断在说redu_owner_id这个列具有数据倾斜，那么下面早证明一下：

下面来查看，redu_owner_id的值的分布。起首看看两个分歧绑定变量前往的行数：

通过这个消息，我们晓得了，上面SQL因为列的值具有倾斜，导致SQL施行打算部门值施行很快，部门值施行很慢。

大师可能会说，在11G中，SQL引入了ACS功能，可是很倒霉的事在客户这里ACS都是禁用了的。

下面就是怎样来优化这个SQL。在上面提到了子查询中最多前往10行，能够用于做NL的驱动，要让子查询的表做驱动表，该当怎样来点窜SQL?

当然我们也能够通过点窜SQL为 with as 的体例，因为在这个系列的其他案例中利用过，因而我们换一种体例来实现。也就是通过提醒来达到目标。

这里利用cardinality提醒，在SQL解析的时候告诉CBO表上具有几多行。表上具有的行数越少，也就意味着拜候表的成本越低。

每次的逻辑读从本来的369927降低到此刻的45 ，机能提拔很较着，而且次要处理了RAC之间的GC期待，不影响其它的营业了。

优化SQL后，CPU利用率从本来的70%摆布间接下降到25%摆布，此系统的主机机能很NB的，8路的PC ，E7的CPU。

2， 通过cardinality来指定表的行数，达到指定表做驱动表的目标。

好动静：恩墨学院近期推出Oracle ACE 总监专家课程之顶级优化案例课程，在方才过去的周末，Oracle百科全书杨廷琨教员和中国地域首位 Oracle ACE总监盖国强教员别离进行了为期一天的出色分享。从道理讲解、优化思绪到设身处地模仿及演示，这才是 Oracle 数据库实战技术准确的打开体例。现场济济一堂，近程同步直播百人在线讲课新篇章。