Oracle查询转换之链接谓词推入

链接谓词推入(Join Predicate  Pushdown)是优化器处理带视图的目标SQL的一种优化手段，它是指虽然优化器会把该SQL中视图的定义SQL语句看成一个独立单元来单独执行，但此时优化器会把本来处于该视图外部查询中和该视图之间的链接条件推入到该视图的定义SQL语句内部，这样是为了能使用上该视图内部相关基表上的索引，进而能走出基于索引的嵌套循环链接。

链接谓词推入所带来的基于索引的嵌套循环链接并不必定能走出更高效的执行计划，由于当作了链接谓词推入后，原目标SQL中的视图就和外部查询产生了关联，同时Oracle又必须将该视图的定义SQL语句看成一个独立的处理单元单独执行，这也就意味着对于外部查询所在结果集中的每一条记录，上述视图的定义SQL语句都得单独执行一次，这样一旦外部查询所在的结果集的Cardinality比较大的话，即使在执行上述视图的定义语句时能用上索引，整个SQL的执行效率也不定比不作链接谓词推入时的哈希链接或排序合并链接高。因此Oracle在作链接谓词推入时会考虑成本，只有当通过链接谓词推入后走嵌套循环链接的等价改写SQL的成本值小于原SQL的成本值时，Oracle才会对目标SQL作链接谓词推入。

Oracle是否能作链接谓词推入与目标视图的类型、该视图与外部查询之间的链接类型以及链接方法有关。到目前为止，Oracle仅仅支持对以下类型的视图作链接谓词推入。

• 视图定义SQL语句中包含UNION ALL/UNION的视图

• 视图定义SQL语句中包含DISTINCT的视图

• 视图定义SQL语句中包含GROUP BY的视图

• 和外部查询之间的链接类型是外链接的视图

• 和外部查询之间的链接类型是反链接的视图

• 和外部查询之间的链接类型是半链接的视图

看一个链接谓词推入的实例，建立测试表、相关索引和一个普通视图和一个带有UNION ALL的视图

scott@TEST>create table emp1 as select * from emp;

Table created.

scott@TEST>create table emp2 as select * from emp;

Table created.

scott@TEST>create index idx_emp1 on emp1(empno);

Index created.

scott@TEST>create index idx_emp2 on emp2(empno);

Index created.

scott@TEST>create or replace view emp_view as 
  2  select emp1.empno as empno1 from emp1;

View created.

scott@TEST>create or replace view emp_view_union as
  2  select emp1.empno as empno1 from emp1
  3  union all
  4  select emp2.empno as empno1 from emp2;

View created.

执行测试SQL

scott@TEST>select /*+ no_merge(emp_view) */ emp.empno
  2  from emp,emp_view
  3  where emp.empno=emp_view.empno1(+)
  4  and emp.ename='FORD';

     EMPNO
----------
      7902

在上面的SQL中，咱们使用了no_merge hint是为了让Oracle不对视图EMP_VIEW作视图合并，这样就具有了作链接谓词推入的基本条件。这里外部查询和视图EMP_VIEW的链接条件为“emp.empno=emp_view.empno1(+)”，因为已经在视图EMP_VIEW的基表EMP1的列EMPNO上建立了索引IDX_EMP1，并且这里的链接类型又是外链接，根据前面的介绍，对于视图EMP_VIEW而言，全部能作链接谓词推入的条件都已具有，Oracle在执行上面的SQL时会考虑作链接谓词推入。若是作链接谓词推入，执行计划就会 走嵌套循环外链接而且访问视图EMP_VIEW的基表EMP1时会使用列EMPNO上的索引IDX_EMP1。

从执行计划上能够看出，Oracle在执行测试SQL时确实走的是嵌套循环外链接，而且访问视图EMP_VIEW的基表EMP1时用到了索引IDX_EMP1。并且Id=3的执行步骤上Name列的值是“EMP_VIEW”，Operation列的值是“VIEW PUSHED PREDICATE”。这说明Oracle确实没有对视图EMP_VIEW作视图合并，而是把它看成一个独立的执行单元来单独执行，而且把外部查询和视图EMP_VIEW之间的链接条件“emp.empno=emp_view.empno1(+)”推入到了视图的定义语句内部。

若是不作链接谓词推入，那Oracle在访问视图EMP_VIEW的基表EMP1时就只能作全表扫描了。在测试SQL中加入no_push_pred hint(让优化器不要对视图EMP_VIEW作链接谓词推入)再次执行

scott@TEST>select /*+ no_merge(emp_view) no_push_pred(emp_view) */ emp.empno
  2  from emp,emp_view
  3  where emp.empno=emp_view.empno1(+)
  4  and emp.ename='FORD';

     EMPNO
----------
      7902

执行计划已经变为了HASH JOIN OUTER，并且对EMP_VIEW的基表EMP1确实用的是全表扫描。

如今把测试SQL改一下，把EMP_VIEW用EMP_VIEW_UNION视图替换，并把链接类型改成内链接，再次执行

scott@TEST>select emp.empno
  2  from emp,emp_view_union
  3  where emp.empno=emp_view_union.empno1
  4  and emp.ename='FORD';

     EMPNO
----------
      7902
      7902

视图EMP_VIEW_UNION的定义SQL语句中包含UNION ALL，它自己就不能作视图合并，于是具有了作链接谓词推入的基本条件。这里外部查询和视图EMP_VIEW_UNION的链接条件为“emp.empno=emp_view_union.empno1”视图对基表上的EMPNO列都有索引，虽然这里的链接类型是内链接，但对于包含UNION ALL的视图EMP_VIEW_UNION而言，全部能做链接谓词推入的条件都已具有，意味着Oracle地执行上述SQL时作考虑作链接谓词推入。若是作链接谓词推入，那执行计划就会走嵌套循环链接，而且访问视图的基表会用上列EMPNO上的索引。

从执行计划中能够看出，Oracle走的执行计划与预想的同样。

在SQL中加入no_push_pred hint(让优化器不要对视图EMP_VIEW作链接谓词推入)再次执行

scott@TEST>select /*+ no_push_pred(emp_view_union) */emp.empno
  2  from emp,emp_view_union
  3  where emp.empno=emp_view_union.empno1
  4  and emp.ename='FORD';

     EMPNO
----------
      7902
      7902

从执行计划能够看出，不使用链接谓词推入，则对视图的基表作的是全表扫描。

以前提到过，Oracle在作链接谓词推入时会考虑成本，只有通过链接谓词推入后走嵌套循环链接的等价改写SQL的成本值小于原SQL的成本值时，Oracle才会对目标SQL作链接谓词推入。

如今来验证一下，在上面的SQL中加入cardinality hint，让CBO认为外围查询的结果集的Cardinality是1万，这样就会急剧增长作链接谓词推入后的嵌套循环链接的成本，若是Oracle在作链接谓词推入是确实会考虑成本，那么此时Oracle就必定不会再选择作链接谓词推入。

scott@TEST>select /*+ cardinality(emp 10000) */emp.empno
  2  from emp,emp_view_union
  3  where emp.empno=emp_view_union.empno1
  4  and emp.ename='FORD';

     EMPNO
----------
      7902
      7902

scott@TEST>select /*+ cardinality(emp 10000) push_pred(emp_view_union) */emp.empno
  2  from emp,emp_view_union
  3  where emp.empno=emp_view_union.empno1
  4  and emp.ename='FORD';

     EMPNO
----------
      7902
      7902

从上面的测试能够看出使用cardinality hint后Oracle没有选择作链接谓词推入，此时的成本为10，使用push_pred强制作链接谓词推入，看到成本为20008。这也验证了以前说的Oracle在作链接谓词推入会考虑成本。

下面再看使用了内嵌视图且链接类型为外链接的示例：

scott@TEST>select /*+ no_merge(emp_view_inline) */ emp.empno
  2  from emp,(select emp1.empno as empno1 from emp1) emp_view_inline
  3  where emp.empno=emp_view_inline.empno1(+)
  4  and emp.ename='FORD';

     EMPNO
----------
      7902

对于上面的SQL，全部能作链接谓词推入的条件都已具有，从执行计划中也能够看出Oracle确实也作了链接谓词推入。

再回到一开始执行的SQL，把外链接改成内链接，并在其中加入push_pred hint(让优化器对视图EMP_VIEW作链接谓词推入)和USE_NL hint

scott@TEST>select /*+ no_merge(emp_view) use_nl(emp_view) push_pred(emp_view) */ emp.empno
  2  from emp,emp_view
  3  where emp.empno=emp_view.empno1
  4  and emp.ename='FORD';

     EMPNO
----------
      7902

从执行计划来看，Oracle没有作链接谓词推入，由于它不属于开关提到的那几种能作链接谓词推入的情形，即便使用了Hint也不行。

虽然Oracle是否能作链接谓词推入与目标视图是否能作视图合并、是不是内嵌视图没有关系，可是与目标视图的类型、与外查询之间的链接类型及链接方法是有关系的。到目前为止，Oracle里能作链接谓词推入的情形公限于开头提到的那几种类型，若是不属于这些情形，即使是看起来很简单，Oracle也不会作。

参考《基于Oracle的SQL优化》

官方文档：http://docs.oracle.com/cd/E11882_01/server.112/e41573/optimops.htm#i55050