索引失效

数据库使用：隐式转换-》索引失效-》严重性能问题
程序中使用隐式转换是一个很不好的编程习惯,不仅不能客观反应出数据库如何真正地处理数据，而且还会带来一些隐藏的性能问题，下面就是一个示例，说明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)