經定位，是因為一條垃圾 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 耗費，全表掃描和走唯一索引時的效率真是差距太大，全表掃描是大忌！
還好這個表的數據不是很大，不然后果會不堪設想。。
所以在工作中，應該要避免隱式轉換，要使用顯式轉換（轉換函數，），遵循 “字段是什么類型，就用什么類型的” 的原則，多用查詢分析器檢查下。
