《收获，不止SQL优化》 - 获取执行计划的方法对比

explain plan for

步骤1：explain plan for 要执行的SQL步骤2：select * from table(dbms_xplan.display());P.S. 为了显示方便，可以设置格式，例如：set long 10000set pagesize 10000set linesize 10000

无须真正执行，快捷方便

1. 没有输出运行时的相关统计信息(产生多少逻辑读，多少次递归调用，多少次物理读的情况)；2. 无法判断处理了多少行；3. 无法判断表被访问了多少次；

如果某SQL执行时间很长时间猜出结果或返回不了结果

set autotrace on

步骤1：set autotrace on步骤2：在此处执行你的SQL

1. 可以输出运行时的相关统计信息(产生多少逻辑读，多少次递归调用，多少次物理读的情况)；2. 虽然必须要等语句执行完毕后才可以输出执行计划，但是可以有traceonly开关来控制返回结果不打屏输出；

1. 必须要等到语句真正执行完毕后，才可以出结果；2. 无法看到表被访问了多少次；

想粗略知道recursive calls递归调用次数，用这个方法，详细用10046 trace方法

statistics_level=all

步骤1：alter session set statistics_level=all；步骤2：在此处执行你的SQL；步骤3：select * from table(dbms_xplan.display_cursor(null, null, 'allstats last'));

1. 可以清晰地从STARTS得出表被访问多少次；2.可以清晰地从E-ROWS和A-ROWS中得到预测的行数和真实的行数，从而可以准确判断Oracle评估是否准确；3. 虽然没有专门的输出运行时的相关统计信息，但是执行计划中的BUFFERS就是真实的逻辑读的数值；

1. 必须要等到语句真正执行完毕后，才可以出结果；2. 无法控制输出记录展现与否，而autotrace和traceonly可以控制不将输出记录打屏；3. 看不出递归调用的次数，看不出物理读的数值；

要想获取表被访问的次数，只能使用方法3

dbms_xplan.display_cursor

select * from table(dbms_xplan.display_cursor('&sql_id'));，该方法是从共享池中得到

1. 知道sql_id立即可得到执行计划，和explain plan for一样无须执行；2. 可以得到真实的执行计划；

1. 没有输出运行时的相关统计信息(产生多少逻辑读，多少次递归调用，多少次物理读的情况)；2. 无法判断处理了多少行；3. 无法判断表被访问了多少次；

观察某条SQL有多条执行计划的情况

事件10046 trace跟踪

步骤1： alter session set events '10046 trace name context forever, level 12';(开启跟踪)步骤2：执行你的语句；步骤3：alter session set events '10046 trace name context off';(关闭跟踪)；步骤4：找到跟踪后产生的文件；步骤5： tkprof trc文件 目标文件；

1. 可以看出SQL语句对应的等待事件；2. 如果SQL语句中有函数调用，SQL中有SQL，都将会被列出，无处遁形；3. 可以方便地看出处理的行数，产生的物理逻辑读；4. 可以方便地看出解析时间和执行时间；5. 可以跟踪整个程序包；

1. 步骤繁琐，比较麻烦；2. 无法判断表被访问了多少次；3. 执行计划中的谓词部分不能清晰地展现出来；

如果SQL中含函数，函数中又套SQL等，即存在多层调用，想准确分析只能用该方法

awrsqrpt.sql

步骤1： @?/rdbms/admin/awrsqrpt.sql；步骤2：选择你要的断点(begin snap和end snap)；步骤3：输入你的sql_id；

可以方便地看到多个执行计划；

获取的过程比较麻烦；

想观察某条SQL的多个执行计划用该方法