踩坑CBO，解决那些坑爹的SQL优化问题_PART4

接PART3：

2.1.3类FILTER问题

  类FILTER问题主要体现在UPDATE关联更新和标量子查询中，虽然此类SQL语句中并未显式出现FILTER关键字，但是内部操作和FILTER操作如出一辙。

  先看下UPDATE关联更新：

这里需要更新14999行，执行计划如下：

  ID=2部分是where exists选择部分，先把需要更新的条件查询出来，之后执行UPDATE关联子查询更新，可以看到ID=5部分出现绑定变量：B1，显然UPDATE操作就类似于原来的FILTER，对于选出的每行与子查询表NEW_TAB关联查询，如果ID列重复值较少，那么子查询执行的次数就会很多，从而影响效率，也就是ID=5的操作要执行很多次。

  当然，这里字段ID唯一性很强，可以建立UNIQUE INDEX，普通INDEX灯，这样第5步就可以走索引了。这里为了举例这种UPDATE的优化方式，不建索引，也可以搞定这样的UPDATE：MERGR和UPDATE INLINE VIEW方式。

  MERGE中直接利用HASH JOIN，避免多次访问操作，从而效率大增，再来看看UPDATE LINE VIEW写法：

UPDATE

  (SELECT a.status astatus,

    b.status bstatus

  FROM old_tab a,

    new_tab b

  WHERE a.id=b.id

  AND a.id  >9000000

  )

SET astatus=bstatus;
要求b.id是preserved key (唯一索引、唯一约束、主键），11g bypass_ujvc会报错，类似MERGE操作。

再来看看标量子查询，标量子查询往往也是引发严重性能问题的杀手：

  
  标量子查询的计划和普通计划的执行顺序不同，标量子查询虽然在上面，但是它由下面的CUSTOMERS表结果驱动（上面的在后面执行，这个与普通执行计划顺序不同），每行驱动查询一次标量子查询（有CACHE例外），同样类似FILTER操作。
  如果对标量子查询进行优化，一般就是改写SQL，将标量子查询改为外连接形式（在约束和业务满足的情况下也可改写为普通JOIN）：

  通过改写之后效率大增，并且使用HASH JOIN算法。下面看一下标量子查询中的CACHE（FILTER和UPDATE关联更新类似），如果关联的列重复值特别多，那么子查询执行次数就会很少，这时候效率会比较好：


  标量子查询和FILTER一样，有CACHE，如上面的emp_a有108K的行，但是重复的department_id只有11,这样只查询只扫描11次，扫描子查询表的次数少了，效率会提升。

  针对FILTER性能杀手问题，主要分享这3点，当然，还有很多其它值得注意的地方，这需要我们日常多留心和积累，从而熟悉优化器一些问题的处理方法。

未完待续，见PART5：