一条垃圾SQL,把 64 核 CPU 快跑崩了!

最近系统出了一个严重问题,应用程序卡崩致使不可用,把 Oracle 数据库服务器 64 核 CPU 快被跑满了:java

经定位,是由于一条垃圾 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、后端、架构、阿里巴巴等大厂最新面试题

生活很美好,明天见~

相关文章
相关标签/搜索