一條垃圾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 耗費，全表掃描和走唯一索引時的效率真是差距太大，全表掃描是大忌！

還好這個表的數據不是很大，不然後果會不堪設想。。

所以在工作中，應該要避免隱式轉換，要使用顯式轉換（轉換函數，），遵循 "字段是什麼類型，就用什麼類型的" 的原則，多用查詢分析器檢查下。

閱讀更多 Java領域佼佼者 的文章

關鍵字: 信息安全 MySQL 轉換