《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.1 执行计划的基本数据

2.1 执行计划的基本数据

我们用代码清单2-1中的查询计划为例,解释计划访问中基本数据的含义。
代码清单2-1执行计划查询

HELLODBA.COM>exec sql_explain('select o.owner, o.object_name, o.object_id from t_users u, t_objects o
where u.username=o.owner and o.object_name like :A and u.user_id=:B','BASIC PREDICATE');
Plan hash value: 2133435147

---------------------------------------------------
| Id  | Operation                    | Name       |
---------------------------------------------------
|   0 | SELECT STATEMENT             |            |
|   1 |  NESTED LOOPS                |            |
|   2 |   TABLE ACCESS BY INDEX ROWID| T_USERS    |
|*  3 |    INDEX UNIQUE SCAN         | T_USERS_PK |
|*  4 |   TABLE ACCESS FULL          | T_OBJECTS  |
---------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("U"."USER_ID"=TO_NUMBER(:B))
   4 - filter("O"."OBJECT_NAME" LIKE :A AND "U"."USERNAME"="O"."OWNER")

这里利用DBMS_XPLAN显示查询计划,它以表格样式输出查询计划。该表有多个列,其中ID是计划中每个操作的唯一序列号,Operation是每个操作的名称和方式,Name是操作的对象。实际上,该表还有其他一些列代表了优化、统计等信息,我们将在下一节解释这些列的含义。
我们再看每行记录的数据。如果留意看,就不难发现每行数据中的Operation都带有长短不一的前导空格,使之看起来成为一个树状结构。这个结构也就是我们之前提到的操作之间的调用关系。下面分析每一行:
首先看第一条,ID为0,操作为SELECT STATEMENT。这一行实际上只表示这条语句的类型是一条SELECT语句,而非一个真正的操作。因此在一些执行计划的显示当中,没有显示ID为0的操作。
ID为1的操作是NESTED LOOPS,表明它需要对两个数据集以嵌套循环的方式进行数据关联。而这两个数据集则是由其两个子操作2和4分别从表T_USERS和T_OBJECTS上读取得来,也就是说,操作1按顺序调用操作2和4,获取它们返回的数据进行关联。而要实现嵌套循环,就需要两个循环体。其中,操作2就是第一个循环体,也就是外循环;操作4就是第二个循环体,即内循环。
ID为2的操作是TABLE ACCESS BY INDEX ROWID,Name是T_USERS,表明它是通过索引上的ROWID来访问表T_USERS以获取数据。而索引上的ROWID则需要通过其子操作3来获取;
ID为3的操作是INDEX UNIQUE SCAN,Name是T_USERS_PK,表明它是对索引T_USERS_PK进行唯一键值的访问以获取其父操作所需要的ROWID。从之前的DDL语句我们知道,T_USERS_PK是表T_USERS的主键,也是一个唯一索引。而对唯一索引的唯一键值的访问,需要有一个数值的输入作为访问条件。在它的ID列,我们可以留意到*符号,表示这个操作有相关的谓词条件(访问条件或者过滤条件)。而我们这里也特地显示了谓词条件。在下面谓词信息输出部分,可以找到一条信息3 - access("U"."USER_ID"=TO_NUMBER(:B)),表明这是操作ID为3的谓词条件,其中access表示它是访问条件,内容是通过某个数值定位USER_ID键值。
提示:访问条件和过滤条件都属于谓词条件,但它们对操作的作用大不相同。访问条件可以帮助操作从物理对象上定位到符合条件的数据,然后再读取数据;而过滤条件是操作已经从物理存储上读取到了数据,然后将不符合条件的数据过滤掉。它们对语句的性能影响很大,了解了它们之间的差别,就有助于我们对语句进行进一步调优。
ID为4的操作是TABLE ACCESS FULL,Name是T_OBJECTS,表明它是对表T_OBJECTS进行全表扫描。全表扫描即读取表的物理段(Segment)的高水位线(High Water Mark,HWM)以下的所有数据块。同样,它的ID也有*符号,从谓词信息部分可以找到关联的谓词条件4 - filter("O"."OBJECT_NAME" LIKE :A AND "U"."USERNAME"="O"."OWNER")。filter表明它是一个过滤条件,即读取了表T_OBJECTS的所有数据,再过滤掉不符合条件("O"."OBJECT_NAME" LIKE :A AND "U"."USERNAME"="O"."OWNER")的数据。
通过执行计划,我们就可以清楚地了解一条语句是通过什么样的方式读取物理对象的数据,如何对数据进行处理(过滤、排序等),最终获取到符合条件的数据。再结合执行计划中的其他数据,我们就可以进一步定位语句的性能瓶颈在哪里,从而为我们实施优化奠定基础。

时间: 2024-11-05 20:46:47

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.1 执行计划的基本数据的相关文章

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一第一篇 执行计划

第一篇 执行计划 执行计划是指示Oracle如何获取和过滤数据.产生最终结果集,是影响SQL语句执行性能的关键因素.我们在深入了解执行计划之前,首先需要知道执行计划是在什么时候产生的,以及如何让SQL引擎为语句生成执行计划. 在深入了解执行计划之前,我们先了解SQL语句的处理执行过程.当一条语句提交到Oracle后,SQL引擎会分为三个步骤对其处理和执行:解析(Parse).执行(Execute)和获取(Fetch),分别由SQL引擎的不同组件完成.SQL引擎的组件如图1-1所示. 1. SQL

《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): -------------------------

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一1.1 生成执行计划

1.1 生成执行计划 在Oracle中,任何一条语句在解析过程中都会生成一个唯一的数值标识,即SQL_ID.而同一条语句,在解析过程中,可能会因为执行环境的改变(例如某些优化参数被改变)而生成多个版本的游标,不同的游标会有不同的执行计划.每个游标都会按顺序赋予一个序列号,即CHILD_NUMBER,一条语句生成的第一个游标的CHILD_NUMBER为0:相应的,Oracle会为每个执行计划生成一个哈希值以作区分.而多个不同版本的游标,其执行计划可能会相同,也可能不同. 因此,我们可以知道,一条合

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.4 执行计划各个操作的含义

2.4 执行计划各个操作的含义 通常我们所说的执行计划操作包含两个部分:操作与其选项.例如,哈希关联反关联(HASH JOIN ANTI)中,哈希关联(HASH JOIN)是一种操作,"反"关联(ANTI)则是其选项:该操作还可以与其他选项(如"半"关联,SEMI)配合形成不同的执行计划操作. 执行计划中的操作数量非常多.我们下面列出的操作是Oracle 10gR2中的绝大多数操作.Oracle的每个版本都会有一些新的特性出现,而其中一些新特性又会带来新的操作,或者

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一3.1 启发式查询转换

3.1 启发式查询转换 所有的启发式查询转换都是基于一套优化器内建的规则.在查询转换阶段,转换器会逐个针对这些规则对查询进行检查,确定其是否满足转换规则,一旦满足,转换器就对其进行转换. 3.1.1 简单视图合并 我们知道,视图(View)的实质就是一条查询语句.在解析阶段,语句中的每个视图都会被展开至一个查询块中.如果未做视图合并,优化器则会单独分析每个视图,并为定义视图的查询语句生成一个视图子计划.然后再分析整个查询的其他部分,并生成执行计划.在这种情况下,由于视图的执行计划和整体执行计划不

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一1.2 显示执行计划

1.2 显示执行计划 我们现在知道,有三个途径可以获取查询计划:v$sql_plan.dba_hist_sql_plan和PLAN_TABLE.如果需要读取一条SQL语句的执行计划,就需要知道该条语句的SQL_ID,如果该语句存在多个游标或者执行计划,则还需要知道游标的CHILD_NUMBER或计划的哈希值(可选).而无论我们通过哪个途径来获取执行计划,显示方式主要是两种:语句查询和包DBMS_XPLAN显示. 1.2.1 通过查询语句显示计划 通过查询语句从一些视图里读出执行计划并作格式化输出

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.2 内部函数与操作

2.2 内部函数与操作 实际上,在Oracle内部,执行计划的每一个数据源(Row Source)操作都与一个内部函数(qer<*>)相对应,而操作对象.谓词条件都是这些函数的参数.这些函数之间可以相互调用,也正是这些函数的调用关系,映射成为执行计划的树状关系.换句话说,一个执行计划告诉Oracle的内部引擎如何调用这些函数,以及传给函数的参数值.例如,在上述例子中,NESTED LOOPS获取数据的内部函数是qerjoFetch:TABLE ACCESS BY INDEX ROWID的内部函

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一3.2 基于代价的查询转换

3.2 基于代价的查询转换 在进行基于代价的查询转换时,转换器先确认查询是否满足转换条件.一旦满足,就会对各种可行的转换方式进行枚举,并对它们进行代价估算,找到代价最低的方式.由此可见,相对于启发式查询转换,基于代价的查询转换是一个相当消耗资源(CPU和内存)的过程.提示:Oracle中有一个优化器参数_OPTIMIZER_COST_BASED_TRANSFORMATION,用它来控制是否进行基于代价的查询转换,以及如何进行基于代价的查询转换,从而限制其对资源的消耗. 3.2.1 复杂视图合并

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.3 执行计划各个列的含义

2.3 执行计划各个列的含义 在执行计划中,除了ID.Operation和Name之外,还有其他一些列.这些列的数据是根据需要从PLAN_TABLE.V$SQL_PLAN.V$SQL_PLAN_STATISTICS_ALL等表和视图中读取的.它们可以帮助我们进一步理解该执行计划(例如优化器对各个操作的估算数据.实际运行中各个操作的性能数据等).以下就是各个列的描述. Rows/E-Rows:优化器估算出当前操作返回给上一级操作的数据记录数,如果计划中同时输出收集到实际记录数,则会显示为E-Row