这个是《老虎刘谈oracle性能优化》微信公众号的第一篇文章,有一点小瑕疵,放在这里更正一下:
说隐式类型转换发生在变量上是“无害的”的说法是不妥的:如果绑定变量是number字段,而且字段上存在直方图,隐式类型转换相当于在变量上使用了函数。这种情况下,绑定变量窥视在第一次会通过直方图做出正确估值,但是如果绑定变量值发生巨大变化,也不再窥视(不再被标记绑定变量敏感),即使开启了ACS和bind_aware,也会一直沿用第一次硬解析时生成的执行计划,这也是一个比较大的问题。 当然,对于数据分布比较平均的字段来说,这种情况就没有问题。
以下是公众号原文:
前几天,有个给运营商做维护的DBA小陈问:
刘老师,我这个SQL不能使用索引,你帮我确认一下,是不是遇到了“隐式类型转换”?然后发了一个执行计划的最后部分给我看:
Peeked Binds (identified by position):
————————————–
1 – :V1 (VARCHAR2(30), CSID=852): ‘4000874’
2 – :V2 (VARCHAR2(30), CSID=852): ‘4000874’
Predicate Information (identified by operation id):
—————————————————
4 – filter((“RATABLE_RESOURCE_ID”=TO_NUMBER(:V1) OR “TRANSFER_RESOURCE_ID”=TO_NUMBER(:V2)))
我说没错,确实是有隐式类型转换。但是,这个隐式类型转换却是“无害”的,因为如果字段是number类型,绑定变量是varchar2类型,这种隐式类型转换是不会影响SQL执行计划的。而如果字段是varchar2类型,绑定变量是number类型,这种才是最危险的。
小陈接下来发了完整的SQL,并告知第一个谓词条件字段(红色)上有主键:
SELECT
……
FROM hss.tb_bil_ratable_resource
WHERE ratable_resource_id = ‘4000874’ OR transfer_resource_id = ‘4000874’;
我一看SQL,马上就明白是什么原因了:这个SQL如果要想使用索引,必须还要创建另一个谓词条件字段(transfer_resource_id)上的索引。
小陈创建完索引后很快就发消息说搞定了!
解释:
因为两个谓词条件之间的关系是OR,而不是通常见到的AND,如果是AND,不用创建另一个字段上的索引就可以使用已经存在的主键索引。
总结:
这个SQL虽然非常简单,但是如果没有理解OR和AND的区别,还是会比较迷惑。而且客户之前被隐式类型转换折腾过几次,这次发现一个,可惜却不是根因。