执行计划：一条查询语句在ORACLE中的执行过程或访问路径的描述。即就是对一个查询任务，做出一份怎样去完成任务的详细方案。
如果要分析某条SQL的性能问题，通常我们要先看SQL的执行计划，看看SQL的每一步执行是否存在问题。 看懂执行计划也就成了SQL优化的先决条件。 通过执行计划定位性能问题，定位后就通过建立索引、修改sql等解决问题。
一、执行计划的查看
1.1 设置autotrace
autotrace命令如下
|
序号 |
命令 |
解释 |
|
1 |
SET AUTOTRACE OFF |
此为默认值，即关闭Autotrace |
|
2 |
SET AUTOTRACE ON EXPLAIN |
只显示执行计划 |
|
3 |
SET AUTOTRACE ON STATISTICS |
只显示执行的统计信息 |
|
4 |
SET AUTOTRACE ON |
包含2,3两项内容 |
|
5 |
SET AUTOTRACE TRACEONLY |
与ON相似，但不显示语句的执行结果 |
1.2 使用SQL
在执行的sql前面加上EXPLAIN PLAN FOR
SQL> EXPLAIN PLAN FOR SELECT * FROM EMP; 已解释。 SQL> SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE')); 或者： SQL> select * from table(dbms_xplan.display);
1.3 使用PL/SQL Developer，Navicat, Toad等客户端工具
常见的客户端工具如PL/SQL Developer，Navicat, Toad都支持查看解释计划。
Navicat
[SQL] DELETE PLAN_TABLE [SQL] EXPLAIN PLAN FOR SELECT * FROM EMP [SQL] SELECT LPAD(' ', LEVEL-1) || OPERATION || ' (' || OPTIONS || ')' "Operation", OBJECT_NAME "Object", OPTIMIZER "Optimizer", COST "Cost", CARDINALITY "Cardinality", BYTES "Bytes", PARTITION_START "Partition Start", PARTITION_ID "Partition ID" , ACCESS_PREDICATES "Access Predicates", FILTER_PREDICATES "Filter Predicates" FROM PLAN_TABLE START WITH ID = 0 CONNECT BY PRIOR ID=PARENT_ID 时间: 0.184s
PL/SQL Developer
二、如何读懂执行计划
2.1执行顺序的原则
执行顺序的原则是：由上至下，从右向左
由上至下：在执行计划中一般含有多个节点，相同级别(或并列)的节点，靠上的优先执行，靠下的后执行
从右向左：在某个节点下还存在多个子节点，先从最靠右的子节点开始执行。
一般按缩进长度来判断，缩进最大的最先执行，如果有2行缩进一样，那么就先执行上面的。
图片是Toad工具查看的执行计划。 在Toad 里面，很清楚的显示了执行的顺序。
以下面的sql为例(sakila样例数据库中的address city country连接查询)
select address.address, city.city, country.country from address inner join city on address.city_id = city.city_id inner join country on city.country_id = country.country_id;
2.2 执行计划中字段解释
ID: 一个序号，但不是执行的先后顺序。执行的先后根据缩进来判断。
Operation： 当前操作的内容。
Rows： 当前操作的Cardinality，Oracle估计当前操作的返回结果集。
Cost（CPU）：Oracle 计算出来的一个数值（代价），用于说明SQL执行的代价。
Time：Oracle 估计当前操作的时间。
在看执行计划的时候，除了看执行计划本身，还需要看谓词和统计信息。 通过整体信息来判断SQL效率。
2.3 谓词说明
Access :
- 通过某种方式定位了需要的数据，然后读取出这些结果集，叫做Access。
- 表示这个谓词条件的值将会影响数据的访问路劲（表还是索引）。
Filter：
- 把所有的数据都访问了，然后过滤掉不需要的数据，这种方式叫做filter 。
- 表示谓词条件的值不会影响数据的访问路劲，只起过滤的作用。
在谓词中主要注意access，要考虑谓词的条件，使用的访问路径是否正确。
2.4 Statistics(统计信息)说明
|
recursive calls |
产生的递归sql调用的条数。
|
|
Db block gets: |
从buffer cache中读取的block的数量 |
|
consistent gets |
从buffer cache中读取的undo数据的block的数量 |
|
physical reads |
从磁盘读取的block的数量 |
|
redo size |
DML生成的redo的大小 |
|
bytes sent via SQL*Net to client |
数据库服务器通过SQL*Net向查询客户端发送的查询结果字节数 |
|
bytes received via SQL*Net from client |
通过SQL*Net接受的来自客户端的数据字节数 |
|
SQL*Net roundtrips to/from client |
服务器和客户端来回往返通信的Oracle Net messages条数 |
|
sorts (memory) |
在内存执行的排序量 |
|
sorts (disk) |
在磁盘上执行的排序量 |
|
rows processed |
处理的数据的行数 |
解释：
Recursive Calls：Number of recursive calls generated at both the user and system level.
Oracle Database maintains tables used for internal processing. When it needs to change these tables, Oracle Database generates an internal SQL statement, which in turn generates a recursive call. In short, recursive calls are basically SQL performed on behalf of your SQL. So, if you had to parse the query, for example, you might have had to run some other queries to get data dictionary information. These would be recursive calls. Space management, security checks, calling PL/SQL from SQL—all incur recursive SQL calls。
当执行一条SQL语句时，产生的对其他SQL语句的调用，这些额外的语句称之为''recursive calls''或''recursive SQL statements''. 我们做一条insert 时，没有足够的空间来保存row记录，Oracle 通过Recursive Call 来动态的分配空间。
DB Block Gets：Number of times a CURRENT block was requested.
Current mode blocks are retrieved as they exist right now, not in a consistent read fashion. Normally, blocks retrieved for a query are retrieved as they existed when the query began. Current mode blocks are retrieved as they exist right now, not from a previous point in time. During a SELECT, you might see current mode retrievals due to reading the data dictionary to find the extent information for a table to do a full scan (because you need the "right now" information, not the consistent read). During a modification, you will access the blocks in current mode in order to write to them.
DB Block Gets:请求的数据块在buffer能满足的个数
当前模式块意思就是在操作中正好提取的块数目，而不是在一致性读的情况下而产生的块数。正常的情况下，一个查询提取的块是在查询开始的那个时间点上存在的数据块，当前块是在这个时刻存在的数据块，而不是在这个时间点之前或者之后的数据块数目。
Consistent Gets： Number of times a consistent read was requested for a block.
This is how many blocks you processed in "consistent read" mode. This will include counts of blocks read from the rollback segment in order to roll back a block. This is the mode you read blocks in with a SELECT, for example. Also, when you do a searched UPDATE/DELETE, you read the blocks in consistent read mode and then get the block in current mode to actually do the modification.
(Consistent Gets: 数据请求总数在回滚段Buffer中的数据一致性读所需要的数据块)
这里的概念是在处理你这个操作的时候需要在一致性读状态上处理多少个块，这些块产生的主要原因是因为由于在你查询的过程中，由于其他会话对数据块进行操作，而对所要查询的块有了修改，但是由于我们的查询是在这些修改之前调用的，所以需要对回滚段中的数据块的前映像进行查询，以保证数据的一致性。这样就产 生了一致性读。
Physical Reads：
Total number of data blocks read from disk. This number equals the value of "physical reads direct" plus all reads into buffer cache.
(Physical Reads:实例启动后，从磁盘读到Buffer Cache数据块数量)
就是从磁盘上读取数据块的数量，其产生的主要原因是：
（1） 在数据库高速缓存中不存在这些块
（2） 全表扫描
（3） 磁盘排序
它们三者之间的关系大致可概括为：
逻辑读指的是Oracle从内存读到的数据块数量。一般来说是'consistent gets' + 'db block gets'。当在内存中找不到所需的数据块的话就需要从磁盘中获取，于是就产生了'physical reads'。
Physical Reads通常是我们最关心的，如果这个值很高，说明要从磁盘请求大量的数据到Buffer Cache里，通常意味着系统里存在大量全表扫描的SQL语句，这会影响到数据库的性能，因此尽量避免语句做全表扫描，对于全表扫描的SQL语句，建议增 加相关的索引，优化SQL语句来解决。
关于physical reads ，db block gets 和consistent gets这三个参数之间有一个换算公式：
数据缓冲区的使用命中率=1 - ( physical reads / (db block gets + consistent gets) )。
用以下语句可以查看数据缓冲区的命中率：
SQL>SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');
查询出来的结果Buffer Cache的命中率应该在90％以上，否则需要增加数据缓冲区的大小。
清空Buffer Cache和数据字典缓存 SQL> alter system flush shared_pool; //请勿随意在生产环境执行此语句 System altered SQL> alter system flush buffer_cache; //请勿随意在生产环境执行此语句 System altered
bytes sent via SQL*Net to client:
Total number of bytes sent to the client from the foreground processes.
bytes received via SQL*Net from client:
Total number of bytes received from the client over Oracle Net.
SQL*Net roundtrips to/from client:
Total number of Oracle Net messages sent to and received from the client.
Oracle Net是把Oracle网络粘合起来的粘合剂。它负责处理客户到服务器和服务器到客户通信，
sorts (memory): 在内存里排序。
Number of sort operations that were performed completely in memory and did not require any disk writes
You cannot do much better than memory sorts, except maybe no sorts at all. Sorting is usually caused by selection criteria specifications within table join SQL operations.
Sorts(disk): 在磁盘上排序。
Number of sort operations that required at least one disk write. Sorts that require I/O to disk are quite resource intensive. Try increasing the size of the initialization parameter SORT_AREA_SIZE.
所有的sort都是优先在memory中做的，当要排序的内容太多，在sort area中放不下的时候，会需要临时表空间，产生sorts(disk)
rows processed
The number of rows processed
更多内容参考Oracle联机文档：Statistics Descriptions
2.5 动态分析
动态统计量收集是Oracle CBO优化器的一种特性。优化器生成执行计划是依据成本cost公式计算出的，如果相关数据表没有收集过统计量，又要使用CBO的机制，就会引起动态采样。
动态采样（dynamic sampling）就是在生成执行计划是，以一个很小的采用率现进行统计量收集。由于采样率低，采样过程快但是不精确，而且采样结果不会进入到数据字典中。
如果在执行计划中有如下提示：
Note -------------dynamic sampling used for the statement
这提示用户CBO当前使用的技术，需要用户在分析计划时考虑到这些因素。 当出现这个提示，说明当前表使用了动态采样。 我们从而推断这个表可没有做过分析。
这里会出现两种情况：
（1） 如果表没有做过分析，那么CBO可以通过动态采样的方式来获取分析数据，也可以或者正确的执行计划。
（2） 如果表分析过，但是分析信息过旧，这时CBO就不会在使用动态采样，而是使用这些旧的分析数据，从而可能导致错误的执行计划。
更多参照为准确生成执行计划更新统计信息-analyze与dbms_stats
三、JOIN方式
3.1 hash join
3.2 merge join
3.3 nested loop
参照：Nested Loops，Hash Join , Sort Merge Join