当前位置: 移动技术网 > IT编程>开发语言>Java > 一条垃圾SQL,把 64 核 CPU 快跑崩了!

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

2020年04月13日  | 移动技术网IT编程  | 我要评论

最近系统出了一个严重问题,应用程序卡崩导致不可用,把 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.

2.

3.

4.

生活很美好,明天见~

如对本文有疑问, 点击进行留言回复!!

相关文章:

验证码:
移动技术网