首页 > 代码库 > 关于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隐式转换后性能问题
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。