笔者经常使用 set auto trace命令查看执行计划
利用 AUTOTRACE查看执行计划会带来一个额外的好处,当SQL执行完毕之后，会在执行计划的末尾显示SQL在运行过程中耗费的一些统计信息。
recursive calls表示道归调用的次数。一个SQL第一次执行就会发生硬解析，在硬解析的时候，优化器会隐含地调用一些内部SQL，因此当一个SOL第一次执行， recursive call会大于0第二次执行的时候不需要通归调用， recursive calls会等于0
如果SQL语句中有自定义函数， recursive calls水远不会等于0，自定义函数被调用了多少次， recursive calls就会显示为多少次
sol> create or replace function E-getdname(v_deptno in number) return varchar2 an
v dname dept. dnamettyp,3 begin
4 select dname into v_dname from dept where deptno -v deptno:
return v dname,
6 ond f getdname/
Function created.
SQL一共返回了14行数据，每返回一行数据，就会调用一次自定义函数，所以执行计 中 recursive calls为14 db block gets表示有多少个块发生变化，一般情况下，只有DML语句オ会导致块发生变化，所以查询语句中 db block gets一般为O，如果有延迟块清除，或者SOL语句中调用了CLOB的函数， db block gets也有可能会大于0，不要觉得奇怪
consistent gets表示读，单位是块，在进行SOL优化的时候，我们应该想方设法减少逻辑读个数，通常情况下逻辑读越小，性能也就越好，需要注意的是，逻辑读并不是衡量SL执行快慢的唯一标准，需要结合IO等其他综合因素共同判断。
怎么通过辑读判断一个SQL还存在较大优化空间呢?如果SQL的逻報读远远大子SQL语句中所有表的段大小之和(假设所有表都走全表扫描，表关联方式为 HASH JOIN），那么该SOL就存在较大优化空间。动手能力强的读者可以据此编写一个sQL，抓出SQL逻辑读远远大于语句中所有表段大小之和的SQL语句。
physical reads 表示从磁盘读取了多少个数据块，如果表已经被缓存在 buffer cache中，没有物理读， physical reads等于0
redo size 表示产生了多少字节的重做日志，一般情况下只有DML语句才会产生redo，查询语句一般情况下不会产生redo，所以这里 redo size为0.如果有延迟块清除，查询语句也会产生redo
bytes sent via SQLNET to client表示从数据库服务器发送了多少字节到客户端。 bytes received via SQLNET from client表示从客户端发送了多少字节到服务端。 sQL*Net roundtrips to/ from client.表示客户端与数据库服务端交互次数，我们可以通过设置 handysize减少交互次数。
sorts( memory)和 sorts(disk)分别表示内存排序和磁盘排序的次数。 rows processed表示SQL一共返回多少行数据・我们在做SQL优化的时候最关心这部分数据，因为可以根据SQL返回的行数判断整个SOL应该是走HASH连接还是走嵌套循环。如果 rows processed很大，一般走HASH连接;如果 rows processed很小，一般走嵌套循环。
