关于ORACLE隐式转换后性能问题
浏览数：21 /
时间：2015年06月12日
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’
好了，咱得去处理生产问题了，哎，晚上又得加班上生产。。。所以说，小伙子，做事得仔细！
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
