11gr2全外连接优化执行计划(三)

简介: 在11.2中,Oracle对于全外连接的执行计划进行了优化。 这篇进一步介绍NATIVE_FULL_OUTER_JOIN提示。 11gr2全外连接优化执行计划:http://yangtingkun.

11.2中,Oracle对于全外连接的执行计划进行了优化。

这篇进一步介绍NATIVE_FULL_OUTER_JOIN提示。

11gr2全外连接优化执行计划:http://yangtingkun.itpub.net/post/468/506826

11gr2全外连接优化执行计划(二):http://yangtingkun.itpub.net/post/468/506876

 

 

虽然上一篇介绍了NATIVE_FULL_OUTER_JOINNO_NATIVE_FULL_OUTER_JOIN两个HINT,但是实际上NATIVE_FULL_OUTER_JOIN并没有发挥任何的作用,因为Oracle对全外连接的优化使得新的执行计划的代价比原始执行计划要低,所以Oracle默认就选择这个执行计划,因此看不到NATIVE_FULL_OUTER_JOIN提示的效果。

SQL> SET AUTOT ON
SQL> SELECT T1.ID, T2.ID
  2  FROM T1 FULL OUTER JOIN T2
  3  ON T1.ID = T2.ID;

        ID         ID
---------- ----------
         2          2
         3          3
         4          4
         5          5
         6          6
         7          7
         8          8
                    9
                   10
         1
         0

已选择11行。


执行计划
----------------------------------------------------------
Plan hash value: 53297166

----------------------------------------------------------------------------------
| Id  | Operation             | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |          |     9 |   234 |     9  (12)| 00:00:01 |
|   1 |  VIEW                 | VW_FOJ_0 |     9 |   234 |     9  (12)| 00:00:01 |
|*  2 |   HASH JOIN FULL OUTER|          |     9 |   234 |     9  (12)| 00:00:01 |
|   3 |    TABLE ACCESS FULL  | T1       |     9 |   117 |     4   (0)| 00:00:01 |
|   4 |    TABLE ACCESS FULL  | T2       |     9 |   117 |     4   (0)| 00:00:01 |
----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T1"."ID"="T2"."ID")

Note
-----
   - dynamic sampling used for this statement (level=2)


统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         15  consistent gets
          0  physical reads
          0  redo size
        733  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         11  rows processed

尝试在RBO情况下执行:

SQL> ALTER SESSION SET OPTIMIZER_MODE = CHOOSE;

会话已更改。

SQL> SELECT T1.ID, T2.ID
  2  FROM T1 FULL OUTER JOIN T2
  3  ON T1.ID = T2.ID;

        ID         ID
---------- ----------
         2          2
         3          3
         4          4
         5          5
         6          6
         7          7
         8          8

已选择7行。


执行计划
----------------------------------------------------------
Plan hash value: 3374424389

-----------------------------------------
| Id  | Operation            | Name     |
-----------------------------------------
|   0 | SELECT STATEMENT     |          |
|   1 |  VIEW                | VW_FOJ_0 |
|   2 |   MERGE JOIN         |          |
|   3 |    SORT JOIN         |          |
|   4 |     TABLE ACCESS FULL| T2       |
|*  5 |    SORT JOIN         |          |
|   6 |     TABLE ACCESS FULL| T1       |
-----------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("T1"."ID"="T2"."ID")
       filter("T1"."ID"="T2"."ID")

Note
-----
   - rule based optimizer used (consider using cbo)


统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         14  consistent gets
          0  physical reads
          0  redo size
        700  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
          7  rows processed

SQL> SELECT /*+ NATIVE_FULL_OUTER_JOIN */ T1.ID, T2.ID
  2  FROM T1 FULL OUTER JOIN T2
  3  ON T1.ID = T2.ID;

        ID         ID
---------- ----------
         2          2
         3          3
         4          4
         5          5
         6          6
         7          7
         8          8
                    9
                   10
         1
         0

已选择11行。


执行计划
----------------------------------------------------------
Plan hash value: 53297166

----------------------------------------------------------------------------------
| Id  | Operation             | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |          |     9 |   234 |     9  (12)| 00:00:01 |
|   1 |  VIEW                 | VW_FOJ_0 |     9 |   234 |     9  (12)| 00:00:01 |
|*  2 |   HASH JOIN FULL OUTER|          |     9 |   234 |     9  (12)| 00:00:01 |
|   3 |    TABLE ACCESS FULL  | T1       |     9 |   117 |     4   (0)| 00:00:01 |
|   4 |    TABLE ACCESS FULL  | T2       |     9 |   117 |     4   (0)| 00:00:01 |
----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T1"."ID"="T2"."ID")

Note
-----
   - dynamic sampling used for this statement (level=2)


统计信息
----------------------------------------------------------
          7  recursive calls
          0  db block gets
         31  consistent gets
          0  physical reads
          0  redo size
        733  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         11  rows processed

RBO下显然不会出现最新的执行计划,而加上NATIVE_FULL_OUTER_JOIN提示后,执行计划变为新的外连接。

需要注意RBO的执行计划和运行结果都是错误的,这里是个bug,详细描述可以参考:http://yangtingkun.itpub.net/post/468/507056

 

 

目录
相关文章
|
5月前
|
存储 关系型数据库 MySQL
MySQL查询执行计划详解(EXPLAIN)
一、单表查询 访问方法/访问类型: • const:通过主键值或唯一二级索引与一个常熟进行等值查询(不包括NULL),只会生成一条记录 • ref:普通二级索引与一个常数进行等值比较,可能生成多条记录 • ref_or_null:ref的前提下可以加上or key is null • range:对应的扫描区间为若干个单点扫描区间或范围扫描区间(不包括负无穷到正无穷的范围) • index:扫描区间为全表,但是可以在二级索引中扫描(因为二级索引每条记录占用空间更小,所以需要读的页更少) • all:直接扫描全部的聚集索引记录
|
SQL Oracle 关系型数据库
Oracle优化05-执行计划
Oracle优化05-执行计划
447 0
|
NoSQL MongoDB 开发者
索引的使用 执行计划 | 学习笔记
快速学习 索引的使用 执行计划
索引的使用 执行计划 | 学习笔记
|
SQL 存储 关系型数据库
几个必须掌握的SQL优化技巧(三):Explain分析执行计划
在应用的开发过程中,由于开发初期的数据量一般都比较小,所以开发过程中一般都比较注重功能上的实现,但是当完成了一个应用或者系统之后,随着生产数据量的急剧增长,那么之前的很多sql语句的写法就会显现出一定的性能问题,对生产的影响也会越来越大,这些不恰当的sql语句就会成为整个系统性能的瓶颈,为了追求系统的极致性能,必须要对它们进行优化。
285 0
几个必须掌握的SQL优化技巧(三):Explain分析执行计划
|
SQL 索引 存储
执行计划的生成
原文:执行计划的生成   SQL Server使用许多技术来优化资源消耗: 基于语法的查询优化; 无用计划匹配以避免对简单查询的深度优化; 根据当前分布统计的索引和连接策略; 多阶段的查询优化以控制优化开销; 执行计划缓冲以避免重新生成执行计划;   以上技术按以下顺序执行: 解析器; 代数化器; 查询优化器; 执行计划生成,缓冲和hash计划生成; 查询执行;   其执行顺序如下:    一、解析器(parser)   当查询被提交时,SQL Server将它传递给关系引擎中的解析器。
1122 0
|
SQL 数据库 索引