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

>> 欢迎您客人: 登录 | 注册 | 在线 | 搜索 | 风格 | 帮助 | 统计 | 文章

返回首页

>>与软件开发有关的知识：操作系统，数据库，网络通信等

书籍支持

卫琴直播

品书摘要

在线测试

资源下载

联系我们

Java技术网站 → 『 Java开发技术』 → 『操作系统、网络架构和数据库专题』 → 一条垃圾SQL，把 64 核 CPU 快跑崩了！

您是本文章第 18248 个阅读者

* 贴子主题: 一条垃圾SQL，把 64 核 CPU 快跑崩了！

点赞(0) 收藏

作者:Jacky 发表时间：2020-07-13 00:07:06

消息

查看

搜索

好友

邮件

复制

引用

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

                 点击在新窗口中浏览原图
CTRL+鼠标滚轮放大或缩小

一条垃圾SQL，把 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

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

     结果：导致隐式转换，全表扫描

     当字段类型和查询条件数据类型不一致的时候，如果没有转换函数，就会默认隐式转换，当数据类型不能隐式转换时就会报错。

     再看下数据类型一致时的 Oracle 的查询解释计划：

select .. from xxx where xx_no = '20200400001'

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

     结果：唯一索引扫描

     再看下两个 SQL 的 IO、CPU 耗费，全表扫描和走唯一索引时的效率真是差距太大，全表扫描是大忌！

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

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