经定位,是因为一条垃圾 SQL 引起的!!
其实也就是一条很简单的 SQL:
select .. from xxx where xx_no = 20200400001
为了信息安全,以上 SQL 经过处理。
其实就是根据 XX_NO 查询一 条数据,然后查询条件和字段数据类型不一致,结果隐式转换导致索引失效而全表扫描……
- 字段类型为:NVARCHAR2
- 查询条件类型为:NUMBER
这也是老生常谈的问题了,MySQL 也有同样的问题,SQL很简单,问题很严重!!!
来看下数据类型不一致时的 Oracle 的查询解释计划:
select .. from xxx where xx_no = 20200400001
结果:导致隐式转换,全表扫描
当字段类型和查询条件数据类型不一致的时候,如果没有转换函数,就会默认隐式转换,当数据类型不能隐式转换时就会报错。
再看下数据类型一致时的 Oracle 的查询解释计划:
select .. from xxx where xx_no = ‘20200400001’
结果:唯一索引扫描
再看下两个 SQL 的 IO、CPU 耗费,全表扫描和走唯一索引时的效率真是差距太大,全表扫描是大忌!
还好这个表的数据不是很大,不然后果会不堪设想。。
所以在工作中,应该要避免隐式转换,要使用显式转换(转换函数,),遵循 “字段是什么类型,就用什么类型的” 的原则,多用查询分析器检查下。
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。