一條垃圾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、後端、架構、阿里巴巴等大廠最新面試題

生活很美好，明天見～