◆以下来自：Oracle 执行计划（Explain Plan）：https://www.cnblogs.com/xqzt/p/4467867.html ※ 很强
1，取得执行计划（autotrace）
1.1 设置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等。
二、如何读懂执行计划
2.1执行顺序的原则
执行顺序的原则是：由上至下，从右向左
由上至下：在执行计划中一般含有多个节点，相同级别(或并列)的节点，靠上的优先执行，靠下的后执行
从右向左：在某个节点下还存在多个子节点，先从最靠右的子节点开始执行。
一般按缩进长度来判断，缩进最大的最先执行，如果有2行缩进一样，那么就先执行上面的。
2.2 执行计划中字段解释
ID: 一个序号，但不是执行的先后顺序。执行的先后根据缩进来判断。
Operation： 当前操作的内容。
Rows： 当前操作的Cardinality，Oracle估计当前操作的返回结果集。
Cost（CPU）：Oracle 计算出来的一个数值（代价），用于说明SQL执行的代价。
Time：Oracle 估计当前操作的时间。
2.3 谓词说明
Access :
通过某种方式定位了需要的数据，然后读取出这些结果集，叫做Access。
表示这个谓词条件的值将会影响数据的访问路劲（表还是索引）。
Filter：
把所有的数据都访问了，然后过滤掉不需要的数据，这种方式叫做filter 。
表示谓词条件的值不会影响数据的访问路劲，只起过滤的作用。
在谓词中主要注意access，要考虑谓词的条件，使用的访问路径是否正确。
2.4 Statistics(统计信息)说明
| 统计项目 | 内 容 | 详 细 |
| recursive calls | 产生的递归sql调用的条数。 | 当执行一条SQL语句时，产生的对其他SQL语句的调用，这些额外的语句称之为''recursive calls''或''recursive SQL statements''. 我们做一条insert 时，没有足够的空间来保存row记录，Oracle 通过Recursive Call 来动态的分配空间。 |
| Db block gets | 从buffer cache中读取的block的数量 |
DB Block Gets:请求的数据块在buffer能满足的个数 |
| consistent gets | 从buffer cache中读取的undo数据的block的数量 |
Consistent Gets: 数据请求总数在回滚段Buffer中的数据一致性读所需要的数据块 |
| physical reads | 从磁盘读取的block的数量 |
Physical Reads:实例启动后，从磁盘读到Buffer Cache数据块数量) 它们三者之间的关系大致可概括为： |
| redo size | DML生成的redo的大小 | 执行SQL的过程中产生的重做日志 |
| 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 | 处理的数据的行数 | 处理的行数 |
2.5 动态分析
动态统计量收集是Oracle CBO优化器的一种特性。优化器生成执行计划是依据成本cost公式计算出的，如果相关数据表没有收集过统计量，又要使用CBO的机制，就会引起动态采样。
动态采样（dynamic sampling）就是在生成执行计划是，以一个很小的采用率现进行统计量收集。由于采样率低，采样过程快但是不精确，而且采样结果不会进入到数据字典中。
如果在执行计划中有如下提示：
Note
-------------dynamic sampling used for the statement
这提示用户CBO当前使用的技术，需要用户在分析计划时考虑到这些因素。 当出现这个提示，说明当前表使用了动态采样。 我们从而推断这个表可没有做过分析。
这里会出现两种情况：
（1） 如果表没有做过分析，那么CBO可以通过动态采样的方式来获取分析数据，也可以或者正确的执行计划。
（2） 如果表分析过，但是分析信息过旧，这时CBO就不会在使用动态采样，而是使用这些旧的分析数据，从而可能导致错误的执行计划。
三、JOIN方式 （来自：https://www.cnblogs.com/xqzt/p/4469673.html）
执行计划里,多表之间的连接有三种方式：Nested Loops，Hash Join 和 Sort Merge Join.具体适用哪种类型的连接取决于
1,当前的优化器模式 （ALL_ROWS 和 RULE）
2,取决于表大小
3,取决于连接列是否有索引
4,取决于连接列是否排序
5,下面来介绍三种不同连接工作方式的不同：
3.1 hash join
Hash Join是为那些没有索引或者其中任一个有索引的大表。对于这种情况它是最好的Join类型，为什么呢？因为它能够很好的工作于没有索引的大表和并行查询的环境中，并提供最好的性能。大多数人都说它是Join的重型升降机。
需要注意的是：如果HASH表太大，无法一次构造在内存中，则分成若干个partition，写入磁盘的temporary segment，则会多一个写的代价，会降低效率。
这种方式适用于较小的表完全可以放于内存中的情况，这样总成本就是访问两个表的成本之和。但是在表很大的情况下并不能完全放入内存，这时优化器会将它分割成若干不同的分区，不能放入内存的部分就把该分区写入磁盘的临时段，此时要有较大的临时段从而尽量提高I/O 的性能。
可以用USE_HASH(table_name1 table_name2)提示来强制使用散列连接。
3.2 merge join
Merge Join是为那些在连接列上有索引的表，索引可以是聚族索引或者非聚族索引。Merge是这种情况最好的Join类型，需要两个表都有索引，所以它已经排好序并更容易匹配和返回数据。
Merge Join 是先将关联表的关联列各自做排序，然后从各自的排序表中抽取数据，到另一个排序表中做匹配。
因为merge join需要做更多的排序，所以消耗的资源更多。 通常来讲，能够使用merge join的地方，hash join都可以发挥更好的性能,即散列连接的效果都比排序合并连接要好。然而如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时排序合并连接的性能会优于散列连接。
可以使用USE_MERGE(table_name1 table_name2)来强制使用排序合并连接.
适用情况：
1.RBO模式
2.不等价关联(>,<,>=,<=,<>)
3.HASH_JOIN_ENABLED=false
4. 用在没有索引，并且数据已经排序的情况.
3.3 nested loop
Nested Loop Join是为那些有索引的小表或其中人一个有索引的大表。它对那些小表连接，需要循环执行从一个到另一个表的按行比较的情况下工作最好的。
Nested loops 工作方式是循环从一张表中读取数据(驱动表outer table)，然后访问另一张表（被查找表 inner table,通常有索引）。驱动表中的每一行与inner表中的相应记录JOIN。类似一个嵌套的循环。
对于被连接的数据子集较小的情况，嵌套循环连接是个较好的选择。在嵌套循环中，内表被外表驱动，外表返回的每一行都要在内表中检索找到与它匹配的行，因此整个查询返回的结果集不能太大（大于1 万不适合），要把返回子集较小表的作为外表（CBO 默认外表是驱动表），而且在内表的连接字段上一定要有索引。当然也可以用ORDERED 提示来改变CBO默认的驱动表。
使用USE_NL(table_name1 table_name2)可是强制CBO 执行嵌套循环连接。
适用情况：
适用于驱动表的记录集比较小（<10000）而且inner表需要有有效的访问方法（Index），并且索引选择性较好的时候.
JOIN的顺序很重要，驱动表的记录集一定要小，返回结果集的响应时间是最快的。
四、表访问方式
4.1表访问方式---->全表扫描（Full Table Scans, FTS）
不是说全表扫描不好，事实上Oracle在做全表扫描操作时会使用多块读，ORACLE采用一次读入多个数据块 (database block)的方式优化全表扫描，而不是只读取一个数据块，这极大的减少了I/O总次数，提高了系统的吞吐量，所以利用多块读的方法可以十分高效地实现全表扫描。这在目标表的数据量不大时执行效率是非常高的，但全表扫描最大的问题就在于走全表扫描的目标SQL的执行时间会不稳定、不可控，这个执行时间一定会随着目标表数据量的递增而递增。因为随着目标表数据量的递增，它的高水位线会一直不断往上涨，所以全表扫描该表时所需要读取的数据块的数量也会不断增加，这意味着全表扫描该表时所需要耗费的I/O资源会随之不断增加，当然完成对该表的全表扫描操作所需要耗费的时间也会随之增加。
在Oracle中，如果对目标表不停地插入数据，当分配给该表的现有空间不足时高水位线就会向上移动，但如果你用DELETE语句从该表删除数据， 则高水位线并不会随之往下移动（这在某种程度上契合了"高水位线"的定义，就好比水库的水位，当水库涨水时，水位会往上移，当水库放水后，曾经的最高水位 的痕迹还是会清晰可见）。高水位线的这种特性所带来的副作用是，即使使用DELETE语句删光了目标表中的所有数据，高水位线还是会在原来的位置，这意味着全表扫描该表时Oracle还是需要扫描该表高水位线下的所有数据块，所以此时对该表的全表扫描操作所耗费的时间与之前相比并不会有明显的改观。
使用FTS的前提条件：在较大的表上不建议使用全表扫描，除非取出数据的比较多，超过总量的5% -- 10%，或你想使用并行查询功能时。
4.2表访问方式---->通过ROWID访问表（table access by ROWID）
ROWID是一个伪列，即是一个非用户定义的列，而又实际存储于数据库之中。每一个表都有一个ROWID列，一个ROWID值用于唯一确定数据库表中的的一条记录。因此通过ROWID 方式来访问数据也是 Oracle 数据库访问数据的实现方式之一。一般情况下，ROWID方式的访问一定以索引访问或用户指定ROWID作为先决条件，因为所有的索引访问方式最终都会转换为通过ROWID来访问数据记录。(注：index full scan 与index fast full scan除外)由于Oracle ROWID能够直接定位一条记录，因此使用ROWID方式来访问数据，极大提高数据的访问效率
ROWID扫描是指Oracle在访问目标表里的数据时，直接通过数据所在的ROWID去定位并访问这些数据。
从严格意义上来说，Oracle中的ROWID扫描有两层含义：一种是根据用户在SQL语句中输入的ROWID的值直接去访问对应的数据行记录；另外一种是先去访问相关的索引，然后根据访问索引后得到的ROWID再回表去访问对应的数据行记录。
对Oracle中的堆表而言，我们可以通过Oracle内置的ROWID伪列得到对应行记录所在的ROWID的值（注意，这个ROWID只是一个伪 列，在实际的表块中并不存在该列），然后我们还可以通过DBMS_ROWID包中的相关方法（dbms_rowid.rowid_object,dbms_rowid.rowid_relative_fno、dbms_rowid.rowid_block_number和 dbms_rowid.rowid_row_number）将上述ROWID伪列的值翻译成对应数据行的实际物理存储地址。
4.3索引扫描
索引范围扫描(INDEX RANGE SCAN)
索引范围扫描（INDEX RANGE SCAN）适用于所有类型的B树索引，当扫描的对象是唯一性索引时，此时目标SQL的where条件一定是范围查询（谓词条件为 BETWEEN、<、>等）；当扫描的对象是非唯一性索引时，对目标SQL的where条件没有限制（可以是等值查询，也可以是范围查询）。 索引范围扫描的结果可能会返回多条记录，其实这就是索引范围扫描中"范围"二字的本质含义。
对于唯一索引，ORACLE是已经进行了正序排列了。也就是唯一索引在进行排序的时候消耗不是很大的，因为它在保存 的时候就按照升序进行保存的。
引唯一性扫描(INDEX UNIQUE SCAN)
索引唯一性扫描（INDEX UNIQUE SCAN）是针对唯一性索引（UNIQUE INDEX）的扫描，它仅仅适用于where条件里是等值查询的目标SQL。因为扫描的对象是唯一性索引，所以索引唯一性扫描的结果至多只会返回一条记录。
索引全扫描（INDEX FULL SCAN）
所谓的索引全扫描（INDEX FULL SCAN）就是指要扫描目标索引所有叶子块的所有索引行。这里需要注意的是，索引全扫描需要扫描目标索引的所有叶子块，但这并不意味着需要扫描该索引的所有分支块。在默认情况下，Oracle在做索引全扫描时只需要通过访问必要的分支块定位到位于该索引最左边的叶子块的第一行索引行，就可以利用该索引叶子块之间的双向指针链表，从左至右依次顺序扫描该索引所有叶子块的所有索引行了。
索引快速扫描(index fast full scan)
未未未未
索引跳跃式扫描（INDEX SKIP SCAN）
索引跳跃式扫描（INDEX SKIP SCAN）适用于所有类型的复合B树索引（包括唯一性索引和非唯一性索引），它使那些在where条件中没有对目标索引的前导列指定查询条件但同时又对该 索引的非前导列指定了查询条件的目标SQL依然可以用上该索引，这就像是在扫描该索引时跳过了它的前导列，直接从该索引的非前导列开始扫描一样（实际的执行过程并非如此），这也是索引跳跃式扫描中"跳跃"（SKIP）一词的含义。
为什么在where条件中没有对目标索引的前导列指定查询条件但Oracle依然可以用上该索引呢？这是因为Oracle帮你对该索引的前导列的所有distinct值做了遍历。
Oracle中的索引跳跃式扫描仅仅适用于那些目标索引前导列的distinct值数量较少、后续非前导列的可选择性又非常好的情形，因为索引跳跃式扫描的执行效率一定会随着目标索引前导列的distinct值数量的递增而递减。