一条垃圾SQL，把 64 核 CPU 快跑崩了！

最近系统出了一个严重问题，应用程序卡崩导致不可用，把 oracle 数据库服务器 64 核 cpu 快被跑满了：

经定位，是因为一条垃圾 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 耗费，全表扫描和走唯一索引时的效率真是差距太大，全表扫描是大忌！

还好这个表的数据不是很大，不然后果会不堪设想。。

所以在工作中，应该要避免隐式转换，要使用显式转换（转换函数，），遵循 "字段是什么类型，就用什么类型的" 的原则，多用查询分析器检查下。

推荐去我的博客阅读更多：

1.java jvm、集合、多线程、新特性系列教程

2.spring mvc、spring boot、spring cloud 系列教程

3.maven、git、eclipse、intellij idea 系列工具教程

4.java、后端、架构、阿里巴巴等大厂最新面试题

生活很美好，明天见～