解释计划 与 执行计划的 区别
随着可以得到解释计划输出的开发工具, 比如 toad 的普遍使用, 生成解释计划就变的相当简单. 而不简单的是得到执行计划.
EXPLAIN PLAN 用来显示优化器为SQL语句所选择的执行计划. 你需要了解一件事, 当你得到了解释计划输出的时候, 你其实是得到了当SQL语句执行的时候应该采用的预期执行计划. 你并没有得到实际的执行计划以及与其相关的数据源执行统计信息. 你所得到的只是估计值, 而不是实际值. 在下面, 我将通过将估计的信息成为解释计划输出而把实际信息成为执行计划输出来区分实际的和预期的执行计划.
解释计划输出最令人沮丧的地方就是它与实际执行时所使用的计划可能是不一致的. 使用解释计划的时候有以下3点可能导致计划输出与实际执行计划不一致的地方.
解释计划不考虑绑定变量的数据类型并假设所有的绑定变量都是字符串类型的方式. 然而, 当语句真正执行的时候所准备的执行计划却要考虑数据类型. 需要牢记的一个预期行为: 谓语(where语句中的那些条件)必须严格匹配索引定义, 否则不会使用索引.
按照执行计划的顺序显示
select id, parent_id, operation
from (
select level lvl, id, parment_id, lpad(‘’, level) || operation || ‘’ ||options || ‘’ || object_name as operation
from plan_table
start with id = 0
connect by prior_id = parent_id
)
order by lvl desc, id;
解释计划输出中最有用的部分之一就是被称为谓语信息的部分, 在这个部分中, 将会示出 ACCESS_PREDICATES 和 FILTER_PREDICATES 列, 这两列与计划运算列表中的一行(用ID列来指示)相关, 你会发现计划中每一个有相关的访问或筛选谓语的运算, 在其ID的旁边都有一个星号(*), 当你看到星号的时候, 你就知道要在谓语信息部分寻找ID号来确定哪个谓语(where子句中的条件) 是与该运算相关的. 通过使用这些信息你就可以确认用来进行索引访问的列是正确(或不正确)的, 并且可以确定在哪里进行了条件过滤.
较晚的进行过滤时常见的性能抑制剂.
当一条SQL语句执行的时候将会生成该语句的实际执行计划. 在语句被硬解析之后, 所选的执行计划就会被存到库告诉缓存中以便以后使用. 可以通过查询 v$SQL_PLAN来查看计划运算.
查询最近生成的SQL语句: V$SQL
有好几种方法可以用来查看任何值钱已经执行过的SQL语句保存在库高速缓存中的执行计划.
1. 利用 dbms_xplan.display_cursor 函数
select /*+ gather_plan_statistics */ empno, ename from scott.emp where ename = ‘KING’;
set serveroutput off
select * from table(dbms_xplan.display_cursor(null, null, ‘ALLSTATS LAST’));