1、explain plan for ：如果某SQL执行非常长时间才会出结果，甚至慢到返回不了结果，这时候看执行计划就只能用方法1,或者方法4； 缺点：没有输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况），无法判断是处理了多少行，无法判断表被访问了多少次
2、set auto trace on：不一定是最真实得执行计划，但是能很容易的看出是否排序； 缺点：必须要等到语句真正执行完毕后，才可以出结果，无法看到表被访问了多少次
3、Events 10046 ：能获得真实的执行计划、统计信息，以及等待事件，如果SQL语句中有函数调用，SQL中有SQL，将会都被列出，无处遁形，可以跟踪整个程序包； 缺点：步骤繁琐，比较麻烦，无法判断表被访问了多少次，执行计划中的谓词部分不能清晰的展现出来。
4、dbms_xplan.display_cursor：可能通过SQL_ID和child id获得某条语句的一条、或多条执行计划； 缺点： 没有输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况），无法判断是处理了多少行，无法判断表被访问了多少次。
5、修改statistics_level=all参数 ：能很明显地看出表被访问次数、预估条数、实际条数、实际事件的信息； 缺点： 无法控制记录输屏打出，不像autotrace有 traceonly 可以控制不将结果打屏输出，看不出递归调用的次数，看不出物理读的多少（不过逻辑读才是重点）
6、awrsqrpt.sql ： 能显示某一事件段内指定SQL的执行计划