Oracle & Starcraft

create table fenbu as select 1 id,’Y’ flag from dba_objects where rownum<100001;

insert into fenbu values(1,’N');
commit;

create index IDX_FENBU_FLAG on fenbu(flag);

analyze table fenbu compute statistics for table for all columns for all indexes;

var a varchar2(32);
exec :a:=’N';

SQL 10G>set autotrace trace exp;

SQL 10G>alter session set events’10046 trace name context forever,level 12′;  

Session altered.

SQL 10G>select * from fenbu    where   flag=:a;
Execution Plan
———————————————————-

—————————————————————-
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)|
—————————————————————-
|   0 | SELECT STATEMENT  |       | 50001 |   244K|   202  (80)|
|*  1 |  TABLE ACCESS FULL| FENBU | 50001 |   244K|   202  (80)|
—————————————————————-

Predicate Information (identified by operation id):
—————————————————

   1 - filter(”FLAG”=:A)

Note
—–
   - ‘PLAN_TABLE’ is old version
SQL 10G>alter session set events’10046 trace name context off’;

Session altered.

很显然可以看到set autotrace的执行计划是错的，这是因为set auotrace,explain plan等操作
并不会发生bind peeking,它并不会把绑定变量的值反映到执行计划里面，不会去看直方图的
数据分布，所以它生成的计划并不可信，我们可以来看一下10046的真实计划。
select *
from
 fenbu    where   flag=:a
call     count       cpu    elapsed       disk      query    current        rows
——- ——  ——– ———- ———- ———- ———-  ———-
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          4          0           1
——- ——  ——– ———- ———- ———- ———-  ———-
total        4      0.00       0.00          0          4          0           1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 55 

Rows     Row Source Operation
——-  —————————————————
      1  TABLE ACCESS BY INDEX ROWID FENBU (cr=4 pr=0 pw=0 time=102 us)
      1   INDEX RANGE SCAN IDX_FENBU_FLAG (cr=3 pr=0 pw=0 time=78 us)(object id 83455)