| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 5 | | |
|* 2 | FILTER | | | | | |
|* 3 | INDEX RANGE SCAN| IDX_T1 | 503 | 2515 | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(TO_NUMBER(:X)<=TO_NUMBER(:Y))
3 - access("OBJECT_ID">=TO_NUMBER(:X) AND "OBJECT_ID"<=TO_NUMBER(:Y))
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
451 consistent gets
0 physical reads
0 redo size
413 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
从上面可以看出使用SET AUTOTRACE TRACEONLY后得到的执行计划和之前用EXPLAIN PLAN命令得到的执行计划是一样的。即此时的SET AUTOTRACE TRACEONLY所得到的执行计划是不准确的。
结论：通过上面的实验可以证明使用了SET AUTOTRACE命令后显示的执行计划实际上是来源于调用EXPLAIN PLAN命令，而EXPLAIN PLAN命令所得到的执行计划可能是不准确的（特别是在绑定变量的时候），索引使用SET AUTORACE命令的所显示的执行计划可能是不准确的。
ORACLE数据库还有如下方法得到真实的执行计划：
如果是ORACLE 10G及其以上的版本，该SQL的执行计划又已经被ORACLE捕获并存储到了REPOSITORY中，在可以使用AWR SQL报告来得到真实的历史执行计划。