关于ORACLE隐式转换后性能问题

 SELECT TM.MONEY_CODE FROM T_CONTRACT_MASTER T,T_MONEY TM WHERE T.MONEY_ID = TM.MONEY_ID AND T.POLICY_CODE = ?

问题出现：

今儿生产代码性能扫描这段脚本被揪出来了，原因是这玩意儿执行时间过长，把后面的代码兄弟都给堵住了，然后发现这家伙在做全表扫，一

开始纳闷，这不对啊，T.POLICY_CODE上面明明白白的建这索引呢，咋就能全表扫呢，既然会全表扫导致性能下降，那为什么开发环境没有

发现问题呢？然后，猛的一拍脑袋，乖乖，完了开发数据库跟生产库完全不是一个数量级，虽说有时候数据分布会影响Oracle的执行计划，不

过我觉得还是先去看看开发库的执行计划是不是跟生产一样，好消息是，结果完全一致，我是说执行计划完全一致，坏消息是，开发库量小，

看不出问题，生产库就不妙了，看着像是要执行几百年才能执行完成的节奏啊。

解决方案：

　　定位问题，为什么建立了索引但是为什么没有走索引？这里关键的一点其实我没有有说明，POLICY_CODE这玩意儿是varchar2类

型，而传入参数却是number，那么问题来了，碰到这种情况Oracle会做隐式转换，规则是左边转成右边或者右边转成左边又或者左边右边

一起转巴拉巴拉，结果是执行没有问题，但是索引就不走了。

所以呢，为了走索引，就得避免Oracle发生隐式转换，就得保持数据类型一直，在所以呢，以后如果碰到明明是number类型的数据确

被放在vachar2类型的字段上，请在查询的时候加上引号。

SELECT TM.MONEY_CODE FROM T_CONTRACT_MASTER T,T_MONEY TM WHERE T.MONEY_ID = TM.MONEY_ID AND T.POLICY_CODE = ‘123456’

好了，咱得去处理生产问题了，哎，晚上又得加班上生产。。。所以说，小伙子，做事得仔细！