一、什么是执行计划？
执行计划是一条查询语句在Oracle中的执行过程或访问路径的描述。
执行计划描述了SQL引擎为执行SQL语句进行的操作，分析SQL语句相关的性能问题或仅仅质疑查询优化器的决定时，必须知道执行计划；所以执行计划常用语SQL调优。
二、怎么获取执行计划？（6种方法）
方法1：explain plan for explain [ɪkˈspleɪn]解释，说明
（1）获取步骤
步骤1：explain plan for + 跟上你要执行的SQL;
步骤2：select * from table(dbms_xplan.display());
（2）优点
无须真正执行，快捷方便
（3）缺点
1、没有输出运行时的相关统计信息（产生多少逻辑读；多少次递归调用；多少次物理读情况）；
2、无法判断处理了多少行；
3、无法判断表被访问了多少次；
（4）应用场景
如果某SQL执行很长时间才出结果或返回不了结果
--1、explain plan for + 跟上你要执行的SQL
EXPLAIN PLAN FOR
SELECT A.*, B.*
FROM EMP A
LEFT JOIN DEPT B
ON A.DEPTNO = B.DEPTNO
WHERE A.EMPNO IN ('7369', '7499');
--2、dbms_xplan包括一系列函数，主要用于显示SQL语句的执行计划，且不用的情形下使用不同的函数来显示，
--如预估的执行计划则使用display函数，而实际的执行计划则是用display_cursor函数
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
方法2：set autotrace on 【自动跟踪】 trace [treɪs] 追踪
（1）获取步骤
步骤1：:set autotrace on/traceonly
步骤2：在此处执行你的SQL
（2）优点
1、可以输出运行时的相关统计信息（产生多少逻辑读，多少递归调用，多少次物理读的情况）；
2、虽然必须要等语句执行完毕后才可以输出执行计划，但是可以有traceonly开关来控制返回结果不大屏输出。
（3）缺点
1、必须要等语句真正执行完毕后，才可以出结果；
2、无法看到表被访问了多少次。
（4）应用场景
只能粗略知道recursive calls递归调用次数，详细用10046trace事件方法
recursive [rɪˈkɜːrsɪv] 递归
SET AUTOTRACE TRACEONLY
SELECT A.*, B.*
FROM SCOTT.EMP A
LEFT JOIN SCOTT.DEPT B
ON A.DEPTNO = B.DEPTNO
WHERE A.EMPNO IN ('7369', '7499');
方法3：statistics_level=all statistics [stəˈtɪstɪks] 统计，level [ˈlevl] 层次，数量
（1）获取步骤
步骤1：alter session set statistics_level=all;
步骤2：在此处执行你的SQL
步骤3：select * from table(dbms_xplan.display_cursor(null,null,‘allstats last’));
（2）优点
1、可以清晰地从STATS得出表被访问多少次？
2、可以清晰地从E-ROWS和A-ROWS中得到预测的行数和真实的行数，从而可以准确判断oracle评估是否准确？
e-rows即为estimate-rows,是根据表的统计信息得来的预估行数；
a-rows即为actual-rows,是sql在执行过程中实际取到的行数。
3、虽然没有专门的输出运行时的相关统计信息，但是执行计划中的BUFFERS就是真实的逻辑读的数值。
（3）缺点
1、必须要等到语句真正执行完毕后，才可以出结果；
2、无法控制输出记录展现与否，而autotrace有traceonly可以控制不将输出记录打屏；
3、看不出递归调用的次数，看不出物理读的数值。
（4）应用场景
想要获取表被访问的次数，只能用方法3
starts:该SQL执行的次数
E-Rows:为执行计划预计的行数
A-Rows：实际返回的行数，E-Rows和A-Rows作比较，就可以看出具体哪一步执行计划出问题了。
A-Time:每一步实际执行的时间，可以看出耗时的SQL
Buffers：每一步实际执行的逻辑读或一致性读
方法4：dbms_xplan.display_cursor
（1）获取步骤
select * from table(dbms_xplan.display_cursor(‘&sq_id’));(该方法是从共享池里得到)
（2）优点
1、知道sql_id立即可得到执行计划，和explain plan for一样无须执行；
2、可以得到真实的执行计划。
（3）缺点
1、没有输出运行时的相关统计信息（产生多少逻辑读；多少次递归调用；多少次物理读情况）；
2、无法判断处理了多少行；
3、无法判断表被访问了多少次；
（4）应用场景
观察某条SQL有多条执行计划的情况
方法5：事件10046trace跟踪
（1）获取步骤
步骤1：alter session set events’10046 trace name context forever,level 12’;（开启跟踪)
步骤2：执行你的语句
步骤3：alter session set events ‘10046 trace name context off’;(关闭跟踪)
步骤4：exit(退出当前窗口)
步骤5：找到跟踪后产生的文件 路径：此电脑/D/app/Administrator/diag/rdbms/prcl/trace
步骤6：tkprof trc 文件目标文件 【tkprof 是oracle自带的一个命令行工具，主要作用是将原始的跟踪文件转换为格式化的文本文件】
“ Tkprof全称:tool kit profiler trace kernel profiler” 工具包探查器跟踪内核探查器
trace文件(*.trc格式)对开发者来说是不可读的格式，需要把跟踪文件转换为为可读的格式，tkprof命令用是把跟踪文件格式的工具。
tkprof D:\app\Administrator\diag\rdbms\orcl\orcl\TRACE/orcl_ora_4308.trc d:\10046.txt SYS=NO SORT=prsela,exeela,fchela
（2）优点
1、可以看出SQL语句对应的等到事件；
2、如果SQL语句中有函数调用，SQL中有SQL，都将会被列出，无处循形；
3、可以方便地看出处理的行数，产生的物理逻辑读；
4、可以方便地看出解析时间和执行时间；
5、可以跟踪整个程序包
（3）缺点
1、步骤烦琐，比较麻烦；
2、无法判断表被访问了多少次；
3、执行计划中的谓词部分不能清晰地展现出来
（4）应用场景
如果SQL中含有函数，函数中又嵌套SQL等，即存在多层调用，想准确分析只能用该方法
方法6：awrsqrpt.sql
AWR全称叫Automatic Workload Repository-自动负载信息库,AWR 是通过对比两次快照(snapshot)收集到的统计信息。
AWRSQRPT可以生成指定快照区间目标SQL语句的统计报表，可以查看多个执行计划。
这个脚本可以很方便地取出某个sql在某两个快照间隔内，消耗cpu时间，执行次数，逻辑读，物理读，sql的执行计划以及sql的full sql text，对调优非常方便。
报告关注点：SQL ID部分的执行计划个数、Plan statistics 计划统计、Execution Plan 执行计划
Automatic [ˌɔːtəˈmætɪk] 自动的；Workload 工作量；Repository 知识宝典
（1）获取步骤
步骤1：以管理员用户的身份登录
sqlplus / as sysdba
步骤2：执行@?/rdbms/admin/awrsqrpt.sql 生产AWR报告
步骤3：填写要生成的报告格式，支持html和text，html是默认值可直接回车。
步骤4：要求输入要列出snap id的天数，一般最大保存了一个月的快照。依据自己的需要的时间段输入要列出最近几天的快照。
步骤5：要输入AWR报告启和止的snap_id，依据自己要的时间段输入snap id即可
步骤6：sql的id:0k8522rmdzg4k 默认值
查询SQL_ID，sql_text可以从AWR报告拿
select sql_text, last_load_time, t.SQL_ID
from v$sql t
where last_load_time is not null
and sql_text like 'SELECT count(*) from%'
order by t.LAST_LOAD_TIME desc
步骤7：最后要求输入报告名称
填写AWRSQRPT报告的名称，我可以填写awrsqrpt_20190421.html，然后在打印的日志里有文件保存的路径：，比如：D:\oracle\product\11.2.0\dbhome_1\RDBMS\ADMIN\awrsqrpt.html
（2）优点
可以方便地看到多个执行计划
（3）缺点
获取的过程比较麻烦
（4）应用场景
想观察某条SQL的多个执行计划用该方法
