文章插图
经定位，是因为一条垃圾 SQL 引起的！！
其实也就是一条很简单的 SQL：
【一条垃圾SQL，把 64 核 CPU 快跑崩了】select .. from xxx where xx_no = 20200400001为了信息安全，以上 SQL 经过处理 。
其实就是根据 XX_NO 查询一 条数据，然后查询条件和字段数据类型不一致，结果隐式转换导致索引失效而全表扫描……
- 字段类型为：NVARCHAR2
- 查询条件类型为：NUMBER
来看下数据类型不一致时的 Oracle 的查询解释计划：
select .. from xxx where xx_no = 20200400001
文章插图
结果：导致隐式转换，全表扫描
当字段类型和查询条件数据类型不一致的时候，如果没有转换函数，就会默认隐式转换，当数据类型不能隐式转换时就会报错 。
再看下数据类型一致时的 Oracle 的查询解释计划：
select .. from xxx where xx_no = ‘20200400001’
文章插图
结果：唯一索引扫描
再看下两个 SQL 的 IO、CPU 耗费，全表扫描和走唯一索引时的效率真是差距太大，全表扫描是大忌！
还好这个表的数据不是很大，不然后果会不堪设想 。。
所以在工作中，应该要避免隐式转换，要使用显式转换（转换函数，），遵循 “字段是什么类型，就用什么类型的” 的原则，多用查询分析器检查下 。
推荐阅读
- Excel 执行SQL查询函数
- 八张图了解Redis和MySQL数据一致性问题
- MySQL InnoDB索引那点事儿
- 一文让你搞懂MYSQL底层原理。-内部结构、索引、锁、集群
- 为啥阿里巴巴不建议MySQL使用Text类型？
- MySQL 启动失败的常见原因
- 冰激凌是什么垃圾 吃冰淇淋的五种危害
- SQLite 简介
- 漫谈Mysql之主从复制
- 超详细的MySQL工作原理 体系结构