执行计划中各字段各模块描述

      在SQL语句的执行计划中,包含很多字段项和很多模块,其不同字段代表了不同的含义且在不同的情形下某些字段、模块显示或不显示,下
面的描述给出了执行计划中各字段的含义以及各模块的描述。

       有关执行计划中各字段模块的描述请参考: 执行计划中各字段各模块描述
       有关由SQL语句来获取执行计划请参考:     使用 EXPLAIN PLAN 获取SQL语句执行计划
       有关使用autotrace来获取执行计划请参考:启用 AUTOTRACE 功能
       有关display_cursor函数的使用请参考:      dbms_xplan之display_cursor函数的使用

一、执行计划中各字段的描述
  1、基本字段(总是可用的)
        Id                 执行计划中每一个操作(行)的标识符。如果数字前面带有星号,意味着将在随后提供这行包含的谓词信息
        Operation  对应执行的操作。也叫行源操作
        Name        操作的对象名称
  
  2、查询优化器评估信息
        Rows(E-Rows)     预估操作返回的记录条数
        Bytes(E-Bytes)      预估操作返回的记录字节数
        TempSpc               预估操作使用临时表空间的大小
        Cost(%CPU)         预估操作所需的开销。在括号中列出了CPU开销的百分比。注意这些值是通过执行计划计算出来的。
                    换句话说,父操作的开销包含子操作的开销
        Time                       预估执行操作所需要的时间(HH:MM:SS)
  
  3、分区(仅当访问分区表时下列字段可见)
    Pstart        访问的第一个分区。如果解析时不知道是哪个分区就设为KEY,KEY(I),KEY(MC),KEY(OR),KEY(SQ)
    Pstop        访问的最后一个分区。如果解析时不知道是哪个分区就设为KEY,KEY(I),KEY(MC),KEY(OR),KEY(SQ)
  
  4、并行和分布式处理(仅当使用并行或分布式操作时下列字段可见)
        Inst        在分布式操作中,指操作使用的数据库链接的名字
        TQ         在并行操作中,用于从属线程间通信的表队列
        IN-OUT          并行或分布式操作间的关系
        PQ Distrib     在并行操作中,生产者为发送数据给消费者进行的分配
  
  5、运行时统计(当设定参数statistics_level为all或使用gather_plan_statistics提示时,下列字段可见)
        Starts         指定操作执行的次数
        A-Rows     操作返回的真实记录数
        A-Time      操作执行的真实时间(HH:MM:SS.FF)
  
  6、I/O 统计(当设定参数statistics_level为all或使用gather_plan_statistics提示时,下列字段可见)
        Buffers     执行期间进行的逻辑读操作数量
        Reads      执行期间进行的物理读操作数量
        Writes      执行期间进行的物理写操作数量        
  
  7、内存使用统计
        OMem        最优执行所需内存的预估值
        1Mem         一次通过(one-pass)执行所需内存的预估值
        0/1/M          最优/一次通过/多次通过(multipass)模式操作执行的次数
        Used-Mem       最后一次执行时操作使用的内存量
        Used-Tmp        最后一次执行时操作使用的临时空间大小。这个字段必须扩大1024倍才能和其他衡量内存的字段一致(比如,32k意味着32MB)
        Max-Tmp           操作使用的最大临时空间大小。这个字段必须扩大1024倍才能和其他衡量内存的字段一致(比如,32k意味着32MB)

二、执行计划中各模块的描述与举例
  1、预估的执行计划中的各字段与模块 

SQL> explain plan for
  2  select * from emp e,dept d
  3  where e.deptno=d.deptno
  4  and e.ename='SMITH';                                                                                              

Explained.                                                                                                             

/**************************************************/
/* Author: Robinson Cheng                         */
/* Blog:   http://blog.csdn.net/robinson_0612     */
/* MSN:    robinson_0612@hotmail.com              */
/* QQ:     645746311                              */
/**************************************************/                                                                   

SQL> set linesize 180
SQL> set pagesize 0
SQL> select * from table(dbms_xplan.display(null,null,'advanced'));   --使用dbms_xplan.display函数获得语句的执行计划
Plan hash value: 351108634                                            --SQL语句的哈希植                                

----------------------------------------------------------------------------------------   /*执行计划部分*/
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |     1 |   117 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |         |     1 |   117 |     4   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL          | EMP     |     1 |    87 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    30 |     1   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------                               

Query Block Name / Object Alias (identified by operation id):  --这部分显示的为查询块名和对象别名
-------------------------------------------------------------                                                          

   1 - SEL$1                    --SEL$为select 的缩写,位于块1,相应的还有DEL$,INS$,UPD$等
   2 - SEL$1 / E@SEL$1          --E@SEL$1,对应到执行计划中的操作ID为2上,即在表E上的查询,E为别名,下面类同
   3 - SEL$1 / D@SEL$1
   4 - SEL$1 / D@SEL$1                                                                                                 

Outline Data                    --提纲部分,这部分将执行计划中的图形化方式以文本形式来呈现,即转换为提示符方式
-------------                                                                                                          

  /*+
      BEGIN_OUTLINE_DATA
      USE_NL(@"SEL$1" "D"@"SEL$1")                           --使用USE_NL提示,即嵌套循环
      LEADING(@"SEL$1" "E"@"SEL$1" "D"@"SEL$1")              --指明前导表
      INDEX_RS_ASC(@"SEL$1" "D"@"SEL$1" ("DEPT"."DEPTNO"))   --指明对于D上的访问方式为使用索引
      FULL(@"SEL$1" "E"@"SEL$1")                             --指明对于E上的访问方式为全表扫描
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      OPTIMIZER_FEATURES_ENABLE('10.2.0.3')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */                                                                                                                   

Predicate Information (identified by operation id): --谓词信息部分,在执行计划中ID带有星号的每一行均对应到下面中的一行
---------------------------------------------------                                                                    

   2 - filter("E"."ENAME"='SMITH')
   4 - access("E"."DEPTNO"="D"."DEPTNO")                                                                               

Column Projection Information (identified by operation id):  --执行时每一步骤所返回的列,下面的不同步骤返回了不同的列
-----------------------------------------------------------                                                            

   1 - (#keys=0) "E"."EMPNO"[NUMBER,22], "E"."ENAME"[VARCHAR2,10],
       "E"."JOB"[VARCHAR2,9], "E"."MGR"[NUMBER,22], "E"."HIREDATE"[DATE,7],
       "E"."SAL"[NUMBER,22], "E"."COMM"[NUMBER,22], "E"."DEPTNO"[NUMBER,22],
       "D"."DEPTNO"[NUMBER,22], "D"."DNAME"[VARCHAR2,14], "D"."LOC"[VARCHAR2,13]
   2 - "E"."EMPNO"[NUMBER,22], "E"."ENAME"[VARCHAR2,10], "E"."JOB"[VARCHAR2,9],
       "E"."MGR"[NUMBER,22], "E"."HIREDATE"[DATE,7], "E"."SAL"[NUMBER,22],
       "E"."COMM"[NUMBER,22], "E"."DEPTNO"[NUMBER,22]
   3 - "D"."DEPTNO"[NUMBER,22], "D"."DNAME"[VARCHAR2,14], "D"."LOC"[VARCHAR2,13]
   4 - "D".ROWID[ROWID,10], "D"."DEPTNO"[NUMBER,22]                                                                    

Note    --注释与描述部分,下面的描述中给出了本次SQL语句使用了动态采样功能
-----
   - dynamic sampling used for this statement                                                                          

58 rows selected.

  2、实际执行计划中的各字段与模块    

SQL> select /*+ gather_plan_statistics */ *          --注意此处增加了提示gather_plan_statistics并且该语句被执行
  2  from emp e,dept d
  3  where e.deptno=d.deptno
  4  and e.ename='SMITH';                                                                                              

      7369 SMITH      CLERK           7902 17-DEC-80        800                    20         20 RESEARCH       DALLAS 

SQL> select * from table(dbms_xplan.display_cursor(null,null,'iostats last')); --使用display_cursor获取实际的执行计划  

SQL_ID  fpx7zw59f405d, child number 0              --这部分给出了SQL语句的SQL_ID,子游标号以及原始的SQL语句
-------------------------------------
select /*+ gather_plan_statistics */ * from emp e,dept d where e.deptno=d.deptno and
e.ename='SMITH'                                                                                                        

Plan hash value: 351108634              --SQL 语句的哈希值
                                        --SQL语句的执行计划,可以看到下面显示的字段一部分不同于预估执行计划中的字段
-----------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
-----------------------------------------------------------------------------------------------------------
|   1 |  NESTED LOOPS                |         |      1 |      1 |      1 |00:00:00.01 |      10 |      1 |
|*  2 |   TABLE ACCESS FULL          | EMP     |      1 |      1 |      1 |00:00:00.01 |       8 |      0 |
|   3 |   TABLE ACCESS BY INDEX ROWID| DEPT    |      1 |      1 |      1 |00:00:00.01 |       2 |      1 |
|*  4 |    INDEX UNIQUE SCAN         | PK_DEPT |      1 |      1 |      1 |00:00:00.01 |       1 |      1 |
-----------------------------------------------------------------------------------------------------------            

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

   2 - filter("E"."ENAME"='SMITH')
   4 - access("E"."DEPTNO"="D"."DEPTNO")                                                                               

Note
-----
   - dynamic sampling used for this statement                                                                          

26 rows selected.

三、总结
      由上可知,在不同的情形下可以获得执行计划的不同信息,而不同信息则展现了SQL语句对应的不同情况,因此应根据具体的情形具体分析。                                                                  

时间: 2024-09-16 01:49:38

执行计划中各字段各模块描述的相关文章

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.5 执行计划中其他信息的含义

2.5 执行计划中其他信息的含义 通过DBMS_XPLAN输出执行计划,除了计划本身外,还可以获得一些其他信息帮助我们进一步分析执行计划及语句性能. 2.5.1 查询块和对象别名 在使用DBMS_XPLAN显示执行计划时,选择'ADVANCED'预定义格式作为参数或者加入'ALIAS'控制字符串,可以在输出中看到以下内容: Query Block Name / Object Alias (identified by operation id): -------------------------

浅析SQL SERVER执行计划中的各类怪相

在查看执行计划或调优过程中,执行计划里面有些现象总会让人有些疑惑不解:     1:为什么同一条SQL语句有时候会走索引查找,有时候SQL脚本又不走索引查找,反而走全表扫描?     2:同一条SQL语句,查询条件的取值不同,它的执行计划会一致吗?     3: 同一条SQL语句,其执行计划会变化,为什么     4: 在查询条件的某个或几个字段上创建了索引,执行计划就一定会走该索引吗?     5:同时存在几个索引,SQL语句会走那个索引?      .....................

FAQ系列 | EXPLAIN执行计划中要重点关注哪些要素

导读 EXPLAIN的结果中,有哪些关键信息值得注意呢? MySQL的EXPLAIN当然和ORACLE的没法比,不过我们从它输出的结果中,也可以得到很多有用的信息. 总的来说,我们只需要关注结果中的几列: 列名 备注 type 本次查询表联接类型,从这里可以看到本次查询大概的效率 key 最终选择的索引,如果没有索引的话,本次查询效率通常很差 key_len 本次查询用于结果过滤的索引实际长度,参见另一篇分享(FAQ系列-解读EXPLAIN执行计划中的key_len) rows 预计需要扫描的记

关于执行计划中的%CPU的含义

今天突然想起前段时间学习的一篇博客,是oaktable的Charles Hooper所写,链接为: https://hoopercharles.wordpress.com/2010/02/19/what-is-the-meaning-of-the-cpu-column-in-an-explain-plan/ 自己也趁机消化了一下.对于执行计划中的 列Cost (%CPU),其中的%CPU的含义很少有人能够说得清楚,于是Charles Hooper写了上面的文章来解释. 对于执行计划的信息都会放入

执行计划中常见index访问方式(转)

近期有朋友对于单个表上的index各种情况比较模糊,这里对于单个表上,单个index出现的大多数情况进行了总结性测试,给出了测试结果,至于为什么出现这样的试验结果未做过多解释,给读者留下思考的空间.本篇文章仅仅是为了测试hint对index的影响,而不是说明走各种index方式的好坏.参考: INDEX FULL SCAN vs INDEX FAST FULL SCAN创建表模拟测试 SQL> create table t_xifenfei as select object_id,object_

FAQ系列 | 解读EXPLAIN执行计划中的key_len

导读 EXPLAIN中的key_len一列表示什么意思,该如何解读? EXPLAIN执行计划中有一列 key_len 用于表示本次查询中,所选择的索引长度有多少字节,通常我们可借此判断联合索引有多少列被选择了. 在这里 key_len 大小的计算规则是: 一般地,key_len 等于索引列类型字节长度,例如int类型为4-bytes,bigint为8-bytes: 如果是字符串类型,还需要同时考虑字符集因素,例如:CHAR(30) UTF8则key_len至少是90-bytes: 若该列类型定义

通过执行计划中的CONCATENATION分析sql问题

昨天开发的一个同事找到我,说写了一条sql语句,但是执行了半个小时还没有执行完,想让我帮忙看看是怎么回事. 他大体上给我讲了下逻辑,表bl1_rc_rates是千万级数据量的表,autsu_subscriber 是个临时表,里面只有三百多条数据,bl1_activity_history 表的数据量略小,是百万级的.    select distinct hist.entity_id, rc.* from bl1_activity_history hist, bl1_rc_rates rc, au

SQL Server 2008处理隐式数据类型转换在执行计划中的增强

什么是隐式http://www.aliyun.com/zixun/aggregation/18278.html">数据类型转换: 当我们在语句的where 条件等式的左右提供了不同数据类型的列或者变量,SQL Server在处理等式之前,将其中一端的数据转换成跟另一端数值的数据类型一致,这个过程叫做隐式数据类型转换. 比如 char(50)=varchar(50), char(50)=nchar(50), int=float, int=char(20) 这些where 条件的等式都会触发隐

执行计划中的COLLECTION ITERATOR PICKLER FETCH导致的性能问题

今天开发的同事找到我,让我评估一个sql语句.因为这条语句被应用监控组给抓取出来了,需要尽快进行性能调优. sql语句比较长,是由几个Union连接起来的子查询. xxxxx UNION   SELECT /*+ leading (ar1_creditid_tab ar1_unapplied_credit) use_nl (ar1_creditid_tab ar1_unapplied_credit) */            UNIQUE            0,            MA