首页 > 代码库 > 关于ORACLE隐式转换后性能问题

关于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’

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

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