SELECT TM.MONEY_CODE FROM T_CONTRACT_MASTER T,T_MONEY TM WHERE T.MONEY_ID = TM.MONEY_ID AND T.POLICY_CODE = ?
問題出現：
今兒生產代碼性能掃描這段腳本被揪出來了，原因是這玩意兒執行時間過長，把后面的代碼兄弟都給堵住了，然后發現這家伙在做全表掃，一
開始納悶，這不對啊，T.POLICY_CODE上面明明白白的建這索引呢，咋就能全表掃呢，既然會全表掃導致性能下降，那為什么開發環境沒有
發現問題呢？然后，猛的一拍腦袋，乖乖，完了開發數據庫跟生產庫完全不是一個數量級，雖說有時候數據分布會影響Oracle的執行計划，不
過我覺得還是先去看看開發庫的執行計划是不是跟生產一樣，好消息是，結果完全一致，我是說執行計划完全一致，壞消息是，開發庫量小，
看不出問題，生產庫就不妙了，看着像是要執行幾百年才能執行完成的節奏啊。
解決方案：
定位問題，為什么建立了索引但是為什么沒有走索引？這里關鍵的一點其實我沒有有說明，POLICY_CODE這玩意兒是varchar2類
型，而傳入參數卻是number，那么問題來了，碰到這種情況Oracle會做隱式轉換，規則是左邊轉成右邊或者右邊轉成左邊又或者左邊右邊
一起轉巴拉巴拉，結果是執行沒有問題，但是索引就不走了。
所以呢，為了走索引，就得避免Oracle發生隱式轉換，就得保持數據類型一直，在所以呢，以后如果碰到明明是number類型的數據確
被放在vachar2類型的字段上，請在查詢的時候加上引號。
SELECT TM.MONEY_CODE FROM T_CONTRACT_MASTER T,T_MONEY TM WHERE T.MONEY_ID = TM.MONEY_ID AND T.POLICY_CODE = ‘123456’
好了，咱得去處理生產問題了，哎，晚上又得加班上生產。。。所以說，小伙子，做事得仔細！