执行计划

什么是执行计划

所谓执行计划，顾名思义，就是对一个查询任务，做出一份怎样去完成任务的详细方案。举个生活中的例子，我从珠海要去英国，我可以选择先去香港然后转机，也可以先去北京转机，或者去广州也可以。但是到底怎样去英国划算，也就是我的费用最少，这是一件值得考究

的事情。同样对于查询而言，我们提交的SQL仅仅是描述出了我们的目的地是英国，但至于怎么去，通常我们的SQL中是没有给出提示信息的，是由数据库来决定的。

一、相关的概念

1、Rowid的概念：rowid是一个伪列，既然是伪列，那么这个列就不是用户定义，而是系统自己给加上的。 对每个表都有一个rowid的伪列，但是表中并不物理存储ROWID列的值。不过你可以像使用其它列那样使用它，但是不能删除改列，也不能对该列的值进行 修改、插入。一旦一行数据插入数据库，则rowid在该行的生命周期内是唯一的，即即使该行产生行迁移，行的rowid也不会改变。

2、 Recursive SQL概念：有时为了执行用户发出的一个sql语句，Oracle必须执行一些额外的语句，我们将这些额外的语句称之为'recursive calls'或'recursive SQL statements'.如当一个DDL语句发出后，ORACLE总是隐含的发出一些recursive SQL语句，来修改数据字典信息，以便用户可以成功的执行该DDL语句。当需要的数据字典信息没有在共享内存中时，经常会发生Recursive calls，这些Recursive calls会将数据字典信息从硬盘读入内存中。用户不比关心这些recursive
SQL语句的执行情况，在需要的时候，ORACLE会自动的在内部执行这些语句。当然DML语句与SELECT都可能引起recursive SQL.简单的说，我们可以将触发器视为recursive SQL.

3、Row Source（行源）：用在查询中，由上一操作返回的符合条件的行的集合，即可以是表的全部行数据的集合；也可以是表的部分行数据的集合；也可以为2个row source进行连接操作（如join连接）后得到的行数据集合。

4、Predicate（谓词）：一个查询中的WHERE限制条件

5、Driving Table（驱动表）：该表又称为外层表（OUTER TABLE）。这个概念用于嵌套与HASH连接中。如果该row source返回较多的行数据，则对所有的后续操作有负面影响。注意此处虽然翻译为驱动表，但实际上翻译为驱动行源（driving row source）更为确切。一般说来，是应用查询的限制条件后，返回较少行源的表作为驱动表，所以如果一个大表在WHERE条件有有限制条件（如等值限制），则该大表作为驱动表也是合适的，所以并不是只有较小的表可以作为驱动表，正确说法应该为应用查询的限制条件后，返回较少行源的表作为驱动表。在执行计划中，应该为靠上的那个row
source,在我们后面的描述中，一般将该表称为连接操作的row source 1.

6、Probed Table（被探查表）：该表又称为内层表（INNER TABLE）。在我们从驱动表中得到具体一行的数据后，在该表中寻找符合连接条件的行。所以该表应当为大表（实际上应该为返回较大row source的表）且相应的列上应该有索引。在我们后面的描述中，一般将该表称为连接操作的row source 2.

7、组合索引（concatenated index）：由多个列构成的索引，如create index idx_emp on emp（col1， col2， col3， ……），则我们称idx_emp索引为组合索引。在组合索引中有一个重要的概念：引导列（leading column），在上面的例子中，col1列为引导列。当我们进行查询时可以使用“where col1 = ？ ”，也可以使用“where col1 = ？ and col2 = ？”，这样的限制条件都会使用索引，但是“where col2 = ？
”查询就不会使用该索引。所以限制条件中包含先导列时，该限制条件才会使用该组合索引。

8、可选择性（selectivity）：比较一下列中唯一键的数量和表中的行数，就可以判断该列的可选择性。 如果该列的“唯一键的数量/表中的行数”的比值越接近1，则该列的可选择性越高，该列就越适合创建索引，同样索引的可选择性也越高。在可选择性高的列上进 行查询时，返回的数据就较少，比较适合使用索引查询。

二、oracle访问数据的存取方法

1、全表扫描（Full Table Scans ,FTS）

 为实现全表扫描，Oracle读取表中所有的行，并检查每一行是否满足语句的WHERE限制条件。一个多块读操作可以使一次I/O能读取多块数据块（db_block_multiblock_read_count参数设定），而不是只读取一个数据块，这极大的减 少了I/O总次数，提高了系统的吞吐量，所以利用多块读的方法可以十分高效地实现全表扫描，而且只有在全表扫描的情况下才能使用多块读操作。在这种访问模 式下，每个数据块只被读一次。

 使用FTS的前提条件：在较大的表上不建议使用全表扫描，除非取出数据的比较多，超过总量的5% -10%，或你想使用并行查询功能时。

例：explain plan for select * from dual;

 

2、通过ROWID的表存取（Table Access by ROWID或rowid lookup）

行的ROWID指出了该行所在的数据文件、数据块以及行在该块中的位置，所以通过ROWID来存取数据可以快速定位到目标数据上，是Oracle存取单行数据的最快方法。

这种存取方法不会用到多块读操作，一次I/O只能读取一个数据块。我们会经常在执行计划中看到该存取方法，如通过索引查询数据。

例： explain plan for select * from scott.dept where rowid = 'AAAMgxAAEAAAAAQAAA';

 

3、索引扫描（Index Scan或index lookup）

在索引中，除了存储每个索引的值外，索引还存储具有此值的行对应的ROWID值。

索引扫描可以由2步组成：

 （1） 扫描索引得到对应的rowid值（对于非唯一索引可能返回多个rowid值）

 （2） 通过找到的rowid从表中读出具体的数据。

 每步都是单独的一次I/O，但是对于索引，由于经常使用，绝大多数都已经CACHE到内存中，所以第1步的 I/O经常是逻辑I/O，即数据可以从内存中得到。

 但是对于第2步来说，如果表比较大，则其数据不可能全在内存中，所以其I/O很有可能是物理I/O，这是一个机械操作，相对逻辑I/O来说，是极其费时间的。

 所以如果大表进行索引扫描，取出的数据如果大于总量的5% -10%，使用索引扫描会效率下降很多。

根据索引的类型与where限制条件的不同，有4种类型的索引扫描：

    1）索引唯一扫描（index unique scan）：通过唯一索引查找一个数值经常返回单个ROWID.如果存在UNIQUE 或PRIMARY KEY 约束（它保证了语句只存取单行）的话，Oracle经常实现唯一性扫描。

  例：explain plan for select empno,ename from scott.emp where empno=10;

 

   例：explain plan for select empno from scott.emp where empno=10;

 

   2） 索引范围扫描（index range scan）：

     使用index rang scan的3种情况：

    （a） 在唯一索引列上使用了range操作符（> < <> >= <= between）

    （b） 在组合索引上，只使用部分列进行查询，导致查询出多行

    （c） 对非唯一索引列上进行的任何查询。

  例：select empno,ename from scott.emp where empno > 7876 order by empno;

   3）索引全扫描（index full scan）： 与全表扫描对应，也有相应的全索引扫描。而且此时查询出的数据都必须从索引中可以直接得到。

例： select empno,ename from scott.emp  order by empno;

 

例：create index i_no_name on scott.emp (empno,ename);

    select empno,ename from scott.emp  order by empno;

 

   4） 索引快速扫描（index fast full scan）：扫描索引中的所有的数据块，与 index full scan很类似，但是一个显著的区别就是它不对查询出的数据进行排序，即数据不是以排序顺序被返回。在这种存取方法中，可以使用多块读功能，也可以使用并行读入，以便获得最大吞吐量与缩短执行时间。

例：select priv_id from sm_priv

 

三、表之间的连接

 例：SELECT A.COL1， B.COL2  FROM A， B WHERE A.COL3 = B.COL4；

无论连接操作符如何，典型的连接类型共有3种：

1、排序合并连接 Sort Merge Join （SMJ）

 内部连接过程：

    1） 首先生成row source1需要的数据，然后对这些数据按照连接操作关联列（如A.col3）进行排序。

    2） 随后生成row source2需要的数据，然后对这些数据按照与sort source1对应的连接操作关联列（如B.col4）进行排序。

    3） 最后两边已排序的行被放在一起执行合并操作，即将2个row source按照连接条件连接起来

排序是一个费时、费资源的操作，特别对于大表。基于这个原因，SMJ经常不是一个特别有效的连接方法，但是如果2个row source都已经预先排序，则这种连接方法的效率也是蛮高的。

例：explain plan for

    select a.dname,b.sal from scott.dept a,scott.emp b where a.deptno = b.deptno;

 

2、嵌套循环 Nested Loops （NL）

 内部连接过程：

    Row source1的Row 1 —— Probe ->Row source 2

    Row source1的Row 2 —— Probe ->Row source 2

    Row source1的Row 3 —— Probe ->Row source 2

    Row source1的Row n —— Probe ->Row source 2

 从内部连接过程来看，需要用row source1中的每一行，去匹配row source2中的所有行，所以此时保持row source1尽可能的小与高效的访问row source2（一般通过索引实现）是影响这个连接效率的关键问题。

例： explain plan for

  select /*+ ordered */ e.deptno,d.deptno

    from big_emp e, scott.dept d

   where e.deptno = d.deptno

   order by e.deptno, d.deptno;

 

3、哈希连接（Hash Join）

从理论上来说比NL与SMJ更高效，而且只用在CBO优化器中。

 内部连接过程：

  较小的row source被用来构建hash table与bitmap，第2个row source被用来被hansed，并与第一个row source生成的hash table进行匹配，以便进行进一步的连接。Bitmap被用来作为一种比较快的查找方法，来检查在hash table中是否有匹配的行。特别的，当hash table比较大而不能全部容纳在内存中时，这种查找方法更为有用。这种连接方法也有NL连接中所谓的驱动表的概念，被构建为hash table与bitmap的表为驱动表，当被构建的hash table与bitmap能被容纳在内存中时，这种连接方式的效率极高。

  要使哈希连接有效，需要设置HASH_JOIN_ENABLED=TRUE，缺省情况下该参数为TRUE，另外，不要忘了还要设置 hash_area_size参数，以使哈希连接高效运行，因为哈希连接会在该参数指定大小的内存中运行，过小的参数会使哈希连接的性能比其他连接方式还 要低。

  例：--造大表

       create table big_emp as select *  from SCOTT.EMP;

       insert into big_emp select *  from big_emp;  commit;

 explain plan for

   select /*+ use_hash(emp) */ empno

    from big_emp ,scott.dept

    where big_emp.deptno = dept.deptno;

 

 总结一下，在哪种情况下用哪种连接方法比较好：

    排序合并连接（Sort Merge Join， SMJ）：

    a） 对于非等值连接，这种连接方式的效率是比较高的。

    b） 如果在关联的列上都有索引，效果更好。

    c） 对于将2个较大的row source做连接，该连接方法比NL连接要好一些。

    d） 但是如果sort merge返回的row source过大，则又会导致使用过多的rowid在表中查询数据时，数据库性能下降，因为过多的I/O.

    

    嵌套循环（Nested Loops， NL）：

    a） 如果driving row source（外部表）比较小，并且在inner row source（内部表）上有唯一索引，或有高选择性非唯一索引时，使用这种方法可以得到较好的效率。

    b） NESTED LOOPS有其它连接方法没有的的一个优点是：可以先返回已经连接的行，而不必等待所有的连接操作处理完才返回数据，这可以实现快速的响应时间。

    

    哈希连接（Hash Join， HJ）：

    a） 这种方法是在oracle7后来引入的，使用了比较先进的连接理论，一般来说，其效率应该好于其它2种连接，但是这种连接只能用在CBO优化器中，而且需要设置合适的hash_area_size参数，才能取得较好的性能。

    b） 在2个较大的row source之间连接时会取得相对较好的效率，在一个row source较小时则能取得更好的效率。

    c） 只能用于等值连接中

注意：在下面的语句中，在2个表之间没有连接。

例：explain plan for  select a.deptno,b.deptno from big_emp a,scott.dept b

 

CARTESIAN关键字指出了在2个表之间做笛卡尔乘积。假如表big_emp有n行，dept表有m行，笛卡尔乘积的结果就是得到n * m行结果

四、执行计划阅读

一般按缩进长度来判断，缩进最大的最先执行，如果有2行缩进一样，那么就先执行上面的。

1、执行计划中字段解释：

       ID: 一个序号，但不是执行的先后顺序。执行的先后根据缩进来判断。

       Operation： 当前操作的内容。

       Rows： 当前操作的Cardinality，Oracle估计当前操作的返回结果集。

       Cost（CPU）：Oracle 计算出来的一个数值（代价），用于说明SQL执行的代价。

       Time：Oracle 估计当前操作的时间。

       

2、谓词说明：

Predicate Information (identified by operation id):

---------------------------------------------------

   4 - access("A"."EMPNO"="B"."MG
b438
R")

        filter("A"."EMPNO"="B"."MGR")

   5 - filter("B"."MGR" IS NOT NULL)

       Access: 表示这个谓词条件的值将会影响数据的访问路径（表还是索引）。

       Filter：表示谓词条件的值不会影响数据的访问路径，只起过滤的作用。

       在谓词中主要注意access，要考虑谓词的条件，使用的访问路径是否正确。

       

3、统计信息说明：

db block gets ： 从buffer cache中读取的block的数量    

consistent gets： 从buffer cache中读取的undo数据的block的数量    

physical reads： 从磁盘读取的block的数量    

redo size： DML生成的redo的大小    

sorts (memory) ：在内存执行的排序量    

sorts (disk) ：在磁盘上执行的排序量    

Physical Reads通常是我们最关心的，如果这个值很高，说明要从磁盘请求大量的数据到Buffer Cache里，通常意味着系统里存在大量全表扫描的SQL语句，这会影响到数据库的性能，因此尽量避免语句做全表扫描，对于全表扫描的SQL语句，建议增 加相关的索引，优化SQL语句来解决。

关于physical reads ，db block gets 和consistent gets这三个参数之间有一个换算公式：

数据缓冲区的使用命中率=1 - ( physical reads / (db block gets + consistent gets) )。

用以下语句可以查看数据缓冲区的命中率：

SQL>SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');

 查询出来的结果Buffer Cache的命中率应该在90％以上，否则需要增加数据缓冲区的大小。

它们三者之间的关系大致可概括为：

逻辑读指的是Oracle从内存读到的数据块数量。一般来说是'consistent gets' + 'db block gets'。当在内存中找不到所需的数据块的话就需要从磁盘中获取，于是就产生了'physical reads'。

4、动态分析

   如果在执行计划中有如下提示：

 -dynamic sampling used for the statement

这提示用户CBO当前使用的技术，需要用户在分析计划时考虑到这些因素。 当出现这个提示，说明当前表使用了动态采样。 我们从而推断这个表可能没有做过分析。

动态采样（dynamic sampling）就是在生成执行计划是，以一个很小的采用率现进行统计量收集。由于采样率低，采样过程快但是不精确，而且采样结果不会进入到数据字典中。

这里会出现两种情况：

（1）如果表没有做过分析，那么CBO可以通过动态采样的方式来获取分析数据，也可以或者正确的执行计划。

（2） 如果表分析过，但是分析信息过旧，这时CBO就不会在使用动态采样，而是使用这些旧的分析数据，从而可能导致错误的执行计划。

5、plan_hash_value

select sql_text,hash_value,sql_id from v$sql where plan_hash_value=3956160932;
 

五、查询优化器

 进入Oracle 10g之后，Query Optimizer就已经将CBO作为默认优化器，ALL_ROWS成为Optimizer_Mode的默认参数取值。

ALL_ROWS代表的CBO追求的是生成综合成本最低的SQL执行计划。而FIRST_ROWS追求的是执行计划最快返回结果集合，优先相应前几条的查询结果。所以，FIRST_ROWS与CBO的核心价值有一些差异。

FIRST_ROWS有其用途场景，最多的就是在于分页操作SQL。当结果集合很大的时候，用户或者应用往往不关心全部集合的情况，而是关注返回前几条记录的响应速度。

1、查看查询优化器模式

 show parameter optimizer_mode;

 select name, value from v$parameter where name='optimizer_mode';

 

2、修改查询优化器模式：

alter session set optimizer_mode=RULE;

alter session set optimizer_mode=FIRST_ROWS;

alter session set optimizer_mode=ALL_ROWS;（默认）

alter session set optimizer_mode=CHOOSE;（默认为FIRST_ROWS）

六、相关命令：

1、统计量操作

--清除

SQL> exec dbms_stats.delete_table_stats(user,'T',cascade_parts => true,cascade_columns => true);

--收集

SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true);

2、启用执行过程的命令

SET AUTOTRACE OFF ---------------- 不生成AUTOTRACE 报告，这是缺省模式

SET AUTOTRACE ON ----------------- 包含执行计划和统计信息

SET AUTOTRACE TRACEONLY ------ 同set autotrace on，但是不显示查询输出

SET AUTOTRACE ON EXPLAIN ------ AUTOTRACE只显示优化器执行路径报告

SET AUTOTRACE ON STATISTICS -- 只显示执行统计信息

3、查看执行过程

方式一：set autotrace traceonly

        select * from dual;

方式二：explain plan for select * from dual;

        select * from table (dbms_xplan.display);

             

4、记录所用时间

set timing on;