Oracle性能优化-读懂执行计划

时间 2020-07-10 标签 oracle 性能优化读懂执行计划

Oracle的执行计划

获得执行计划的方式

Autotrace例子

使用Explain

explain plan set STATEMENT_ID='testplan'
for select * from dual;

select lpad(' ',5*(level-1))||operation operation, options,
       object_name, cost,position
  from plan_table
    start with id=0 and STATEMENT_ID='testplan'
    connect by prior id=parent_id ;

怎样看执行计划

看懂执行计划前先须要了解的一些知识

伪列-ROWID

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

Recursive SQL

有时为了执行用户发出的一个sql语句，Oracle必须执行一些额外的语句，咱们将这些额外的语句称之为‘recursive calls’或‘recursive SQL statements’。如当一个DDL语句发出后，ORACLE老是隐含的发出一些recursive SQL语句，来修改数据字典信息，以便用户能够成功的执行该DDL语句。当须要的数据字典信息没有在共享内存中时，常常会发生Recursive calls，这些Recursive calls会将数据字典信息从硬盘读入内存中。用户不比关心这些recursive SQL语句的执行状况，在须要的时候，ORACLE会自动的在内部执行这些语句。固然DML语句也均可能引发recursive SQL。简单的说，咱们能够将触发器视为recursive SQL。

Row Source and Predicate

Row Source(行源)：用在查询中，由上一操做返回的符合条件的行的集合，便可以是表的所有行数据的集合；也能够是表的部分行数据的集合；也能够为对上2个row source进行链接操做(如join链接)后获得的行数据集合。
Predicate(谓词)：一个查询中的WHERE限制条件

Driving Table

Driving Table(驱动表)：该表又称为外层表(OUTER TABLE)。这个概念用于嵌套与HASH链接中。若是该row source返回较多的行数据，则对全部的后续操做有负面影响。注意此处虽然翻译为驱动表，但实际上翻译为驱动行源(driving row source)更为确切。通常说来a，是应用查询的限制条件后，返回较少行源的表做为驱动表，因此若是一个大表在WHERE条件有有限制条件(如等值限制)，则该大表做为驱动表也是合适的，因此并非只有较小的表能够做为驱动表，正确说法应该为应用查询的限制条件后，返回较少行源的表做为驱动表。在执行计划中，应该为靠上的那个row source，后面会给出具体说明。

Probed Table

Probed Table(被探查表)：该表又称为内层表(INNER TABLE)。在咱们从驱动表中获得具体一行的数据后，在该表中寻找符合链接条件的行。因此该表应当为大表(实际上应该为返回较大row source的表)且相应的列上应该有索引。

组合索引(concatenated index)

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

可选择性(selectivity)

比较一下列中惟一键的数量和表中的行数，就能够判断该列的可选择性。若是该列的”惟一键的数量/表中的行数”的比值越接近1，则该列的可选择性越高，该列就越适合建立索引，一样索引的可选择性也越高。在可选择性高的列上进行查询时，返回的数据就较少，比较适合使用索引查询。

oracle访问数据的存取方法（高实战）

索引扫描的细分（Index Scan）

表链接（高实战1）

表链接（高实战2）

表链接（高实战3）

表链接（高实战4）

不一样表链接的相对速度

一个简单的执行计划（在PLSQL-DEVELOPER里按F5,不是F4哈）

再来看2个执行计划（1）

再来看2个执行计划（2）

Oracle中的Hints（提示）

优化器提示

表链接提示

索引提示

并行提示

表访问提示

索引和SQL语句的正确使用

索引-参见《给PLSQL插上飞翔的翅膀-PLSQL优化》中的索引部分
SQL语句-参见《给PLSQL插上飞翔的翅膀-PLSQL优化》中的SQL WHERE和表链接部分

使用ORACLE自带的SQLPLUS

如何让SQLPLUS据有AUTOTRACE功能

以sys用户链接；
运行$ORACLE_HOME/sqlplus目录下的plustrace.sql脚本；
grant plustrace to public，对全部用户有效；
在sql*plus 中运行set autot on命令，将自动跟踪sql的执行计划并提供sql统计资料；

Consistent Gets

第1个不加order by的SQL确定比第2个SQL效率高是毋庸置疑的。

可是为何第2个SQL的consistent gets如此之少?

缘由有以下两点：

一般状况下，不在logical RAM buffer中的数据要经过physical reads来读取，而physical reads后一般会紧跟着一个consistent gets。所以通常状况下consistent gets是要比physical reads大的。可是有一个特例，若是physical reads获得的数据直接用于HASH或者SORT，则只记为physical reads不记为consistent gets。因此加上order by后有可能physical reads多但consistent gets少。不过这个缘由不是我这里现象产生的缘由，由于我这个实验里根本没有physical reads。
arraysize的影响。arraysize是指读取数据时一次读取获得的行数。这个值默认为15，使用show arraysize命令能够查看。一个数据块例若有100条记录，那么并非读取这个块一次就能取到全部数据，以arraysize=15为例，就要有100/15=7次consistent gets。把arraysize设置得大一点能够下降consistent gets，不过有时候可能会消耗更多的资源。若是咱们作select count(0) from test;操做，那么Oracle会把arraysize暂时设为test的行数，所以consistent gets会不多。不多：

AUTOTRACE的几个经常使用选项

set autotrace off ：不生成autotrace 报告，这是缺省模式

set autotrace on explain： autotrace只显示优化器执行路径报告

set autotrace on statistics：只显示执行统计信息

set autotrace on：包含执行计划和统计信息

set autotrace traceonly：同set autotrace on，可是不显示查询输

set autotrace on explain

set autotrace on statistics

set autotrace traceonly

set autotrace traceonly explain

另外一种查看SQL计划的方式-Explain plan

说明：用以查看SQL语句的执行计划

准备：

运行$ORACLE_HOME/rdbms/admin目录下的utlxplan.sql脚本
创建plan_table表
执行方案：explain plan for SQL

Explain Plan-查看执行方案

转载于:https://www.cnblogs.com/aiwz/p/6154596.htmlhtml