如何得到真实的执行计划

通常，我们可以使用如下四种方法来得到目标sql的执行计划：

创新互联于2013年创立，先为湖口等服务建站，湖口等地企业，进行企业商务咨询服务。为湖口企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

（1）explain plan命令

（2）dbms_xplan包

（3）sqlplus中的autotrace开关

（4）10046事件

这其中除了第四种方法之外，其他三种方法得到的执行计划都可能是不准确的。在oracle数据库中判断得到的执行计划是否准确，就是看目标sql是否被真正执行，真正执行过的sql所对应的执行计划就是准确的，反之则可能不准。注意，这里判断原则从严格意义上来说并不适用于autotrace开关，因为所有使用autotrace开关所显示的执行计划都可能是不准的，即使对应的目标sql实际上上已经执行过。

下面我们就用上述原则来判断除了第4种以外的其他三种方法中哪些方法得到的执行计划是准的，哪些方法得到的执行计划可能不准。

对使用第一种方法（explain plan）得到的执行计划而言，因为此时目标sql并没有被实际执行，所以用该方法得到的执行计划有可能是不准的，尤其在目标sql包含绑定变量的时候。在默认开启绑定变量窥探（bind peeking）的情况下，对含绑定变量的目标sql使用explain plan得到执行计划只是一个半成品，oracle在随后对该sql的绑定变量进行窥探后就得到了这些绑定变量具体的值，此时oracle很可能会随上述半成品的执行计划做调整，一旦做了调整，使用explain plan命令得到的执行计划就不准了。

对于使用第二种方法，针对不同的应用场景，你可以选择如下四种方式中的一种：

select * from table(dbms_xplan.display)

select * from table(dbms_xplan.display_cursor(null,null,'advanced')

select * from table(dbms_xplan.display_cursor('sql__id/hash_value',child_cursor_number,'advanced'));

select * from table(dbms_xplan.display_awr('sql_id'));

显然，执行 select * from table(dbms_xplan.display)所得到的执行计划可能是不准确的，因为它只是拥有查看使用explain plan命令得到的目标sql的执行计划，目标sql此时还没有被真正执行，所以用它得到的执行计划可能是不准的。使用剩下的三种方式所得到的执行计划都是准的，因为此时目标sql都已经被实际执行过了。

对于使用第三种方法（sqlplus中的autotrace开关）而言，你可以选择执行如下三种方式中一种来开启autotrace开关

set autotrace on（set antot on）

set autotrace traceonly（set autot trace）

set autotrace traceonly explain（set autot trace exp）

上述三种方式中，当使用set autotrace on和set autotrace traceonly时，目标sql都已经被实际执行过了，正是因为被实际执行过了，所以set autotrace on和set autotrace traceonly的情况下我们能看到目标sql的实际资源消耗情况。当使用set autotrace traceonly explain是，如果执行时select语句，则该select语句并没有被oracle实际执行，但如果执行的是DML语句，情况就不一样了，此时的DML语句会被实际oracle实际执行的。

我们现在来证明上述关于set autotrace traceonly explain的观点。先正常执行一次如下sql：

SQL> select count(*) from emp where ename='JAMES';

COUNT(*)

---------- 1

从如下查询结果中可以看到上述sql所对应的executions的值为1，这说明oracle刚才确实执行了一次上述sql

SQL> select sql_text,executions from v$sqlarea where sql_text like 'select count(*) from emp%';

SQL_TEXT EXECUTIONS

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

select count(*) from emp where ename='JAMES' 1

现在清空shared pool

SQL> alter system flush shared_pool;

System altered.

从如下查询结果中可以看到上述sql所对应的shared cursor现在已经不在shared pool里了

SQL> select sql_text,executions from v$sqlarea where sql_text like 'select count(*) from emp%';

no rows selected

在当前session中已traceonly explain方式打开autotrace后执行上述sql

SQL> set autotrace traceonly explain;

SQL> select count(*) from scott.emp where ename='JAMES'

2 ;

Execution Plan

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

Plan hash value: 2083865914

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

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

| 0 | SELECT STATEMENT | |1 |6 |3 (0)| 00:00:01 |

| 1 | SORT AGGREGATE | |1 |6 | | |

|* 2 | TABLE ACCESS FULL| EMP |1 |6 |3 (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

2 - filter("ENAME"='JAMES')

我们再次查询v$sqlare

SQL> select sql_text,executions from v$sqlarea where sql_text like 'select count(*) from scott.emp%';

SQL_TEXT EXECUTIONS

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

select count(*) from scott.emp where ename='JAMES' 0

从上述查询结果中可以看到该select 语句所对应的EXECUTIONS为0，这说明oracle刚才确实只解析了该select句但并没有实际执行它们。证明上述观点（当使用set autot trace exp时，如果执行的是select语句，则该select语句并没有被oracle实际执行）

接着，在当前session中执行如下DML语句：

SQL> delete from scott.emp where ename='JAMES';

1 row deleted.

Execution Plan

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

Plan hash value: 161811703

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

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

| 0 | DELETE STATEMENT | |1 | 13 |3 (0)| 00:00:01 |

| 1 | DELETE | EMP | | | | |

|* 2 | TABLE ACCESS FULL| EMP |1 | 13 |3 (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

2 - filter("ENAME"='JAMES')

从查询结果可以看到，上述DML语句已经被真正执行了：

SQL> select count(*) from scott.emp where ename='JAMES';

COUNT(*)

----------

SQL> select sql_text,executions from v$sqlarea where sql_text like 'delete from scott.emp%';

SQL_TEXT EXECUTIONS

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

delete from scott.emp where ename='JAMES' 1

从上述实例中我们可以看出使用set autotrace traceonly explain后执行DML语句，该DML语句确实是会被oracle实际执行的，所以在使用set autotrace on，set autotrace traceonly 和set autotrace traceonly explain来获得DML语句的执行计划时要小心，因为这些DML语句实际上已经被执行了。

这里需要特别说明的是，虽然使用set autot 命令后目标sql实际上已经执行过了，但所有使用set autotrace命令（包括 set autotrace on，set autotrace traceonly，set autotrace traceonly explain）所得到的执行计划都可能是不准的，因为使用set autotrace命令所显示的执行计划都是来源于调用explain plan命令。

我们来看一个使用explain plan命令和set autotrace命令后得到的执行计划并不是目标sql真实执行计划的实例。创建一个测试表T1并插入一些数据：

SQL> create table t1 as select * from dba_objects;

Table created.

SQL> insert into t1 select * from t1;

87205 rows created.

SQL> commit;

Commit complete.

现在表T1的数据量是17万多条

SQL> select count(*) from t1;

COUNT(*)

----------

174410

在表T1的列object_id上创建一个单键值的B树索引IDX_T1

SQL> create index idx_t1 on t1(object_id);

Index created.

对表T1收集一个统计信息

SQL> exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname=>'T1',estimate_percent=>100,cascade=>true);

PL/SQL procedure successfully completed.

创建两个绑定变量x和y，分别对他们赋值0和100000

SQL> var x number;

SQL> var y number;

SQL> exec :x=0;

SQL> exec :x:=0;

PL/SQL procedure successfully completed.

SQL> exec :y:=100000;

PL/SQL procedure successfully completed.

用explain plan产生以下sql的执行计划：

SQL> explain plan for select count(*) from t1 where object_id between :x and :y;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT

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

Plan hash value: 2351893609

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

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

| 0 | SELECT STATEMENT | | 1 | 5 | 3 (0)| 00:00:01 |

| 1 | SORT AGGREGATE | | 1 | 5 | | |

|* 2 | FILTER | | | | | |

|* 3 | INDEX RANGE SCAN| IDX_T1 |436 | 2180 | 3 (0)| 00:00:01 |

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

PLAN_TABLE_OUTPUT

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

Predicate Information (identified by operation id):

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

2 - filter(TO_NUMBER(:Y)>=TO_NUMBER(:X))

3 - access("OBJECT_ID">=TO_NUMBER(:X) AND "OBJECT_ID"<=TO_NUMBER(:Y))

16 rows selected.

从上述结果可以看出，使用explain plan命令得到的执行计划显示目标sql走的是对索引IDX_T1索引范围扫描。

但是实际情况时怎样的？我们实际执行该sql：

SQL> exec :x:=0;

PL/SQL procedure successfully completed.

SQL> exec :y:=10000;

PL/SQL procedure successfully completed.

SQL> select count(*) from t1 where object_id between :x and :y;

COUNT(*)

----------

19610

SQL> select * from table(dbms_xplan.display_cursor(null,null,'ADVANCED'));

PLAN_TABLE_OUTPUT

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

SQL_ID9dhu3xk2zu531, child number 0

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

select count(*) from t1 where object_id between :x and :y

Plan hash value: 1410530761

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

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

| 0 | SELECT STATEMENT |||| 107 (100)| |

| 1 | SORT AGGREGATE || 1 | 5 | | |

PLAN_TABLE_OUTPUT

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

|* 2 | FILTER |||| | |

|* 3 | INDEX FAST FULL SCAN| IDX_T1 | 174K| 851K| 107 (1)| 00:00:01 |

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

52 rows selected.

从上述显示内容可以看到，现在目标sql的执行计划实际上走的是索引IDX_T1的索引快速全扫描，这才是目标sql真实的执行计划，几刚才使用explain plan命令得到的执行计划不是准确的。

同样方法可以得到用set autotrace on方法得到的执行计划也不是准确的。

文章名称：如何得到真实的执行计划
本文路径：http://chengdu.cdxwcx.cn/article/poidsc.html

甜橘子，专注成都网站制作网站设计与营销型网站建设与优化

首页

网站建设

网站制作案例

解决方案

网站设计报价

网站制作动态

关于我们

联系我们

成都网站建设设计将想法与焦点和您一起共享

如何得到真实的执行计划

其他资讯

go语言日志处理 golang日志系统

路由器的费电路由器费电吗,不用要关掉吗?

阿里云轻量服务器ip怎么看阿里云轻量级服务器开放端口

linux命令咋装软件 linux安装软件的三种方法

php在数据库搜索数据 php数据库在哪

甜橘子，专注成都网站制作网站设计与营销型网站建设与优化

成都网站建设设计 将想法与焦点和您一起共享

如何得到真实的执行计划

其他资讯

go语言日志处理 golang日志系统

路由器的费电 路由器费电吗,不用要关掉吗?

阿里云轻量服务器ip怎么看 阿里云轻量级服务器开放端口

linux命令咋装软件 linux安装软件的三种方法

php在数据库搜索数据 php数据库在哪

成都网站建设设计将想法与焦点和您一起共享

路由器的费电路由器费电吗,不用要关掉吗?

阿里云轻量服务器ip怎么看阿里云轻量级服务器开放端口