索引失效（转）

数据库使用：隐式转换-》索引失效-》严重性能问题
程序中使用隐式转换是一个很不好的编程习惯,不仅不能客观反应出数据库如何真正地处理数据，而且还会带来一些隐藏的性能问题，下面就是一个示例，说明varchar2与number之间隐式转换导致索引失效，最终导致可以使用索引的地方使用全表扫描，带来严重的性能问题…
下面做个小试验：
SQL> set autotrace on explain   <---打开执行计划监控
SQL> create table t ( id varchar2(20));
Table created.
Elapsed: 00:00:00.04
SQL> begin       <---向表中填入2000000条数据
  2  for i in 1 .. 2000000 loop
  3  insert into t values(i);
  4  end loop
  5  ;
  6  commit;
  7  end;
  8  /
PL/SQL procedure successfully completed.
Elapsed: 00:03:35.33
SQL> select count(*) from t;
  COUNT(*)
----------
   2000000
Elapsed: 00:00:00.08
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=811 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'T' (TABLE) (Cost=811 Card=176780
          7)
SQL> create index id_ind on t( id); <--在Id列上建一个索引
Index created.
Elapsed: 00:00:26.74
SQL> select * from t where id = '200'; <---用字符串查，可以使用到索引（请看执行计划）。
ID
--------------------
200
Elapsed: 00:00:00.01 <---根据索引，只用了00.01秒
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=1 Bytes=12)
   1    0   INDEX (RANGE SCAN) OF 'ID_IND' (INDEX) (Cost=3 Card=1 Byte
          s=12)
从执行计划中可以看出，cost只要3
SQL> select * from t where id = 200; <----如果直接根据数字查，由于发生了隐式转换，执行计划为全表扫描。
ID
--------------------
200
Elapsed: 00:00:00.48 <---全表扫描，是索引扫描时间的48倍！！
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=881 Card=38 Bytes=
          456)
   1    0   TABLE ACCESS (FULL) OF 'T' (TABLE) (Cost=881 Card=38 Bytes
          =456)