"這種該死的問題，他的癥結點一定在一個很白痴的地方，只是我們都還沒找到

有一天某位當初一起上OCP認證的同學打電話給我，表示發生的 full table access ，但離奇的是他有做 index，在他的機器上模擬起來也是一模一樣，index沒有被採用，當時抱著這種神奇的事件一定要觀賞一下，就連線過去看了一下。



測試的方法很簡單，就是create 了一個 table ，塞了很多欄位，再用for迴圈塞了200萬筆資料進去後再建立index，實際select 的時候還是發生full table scan，太神奇了，如下select 語句如下。

select * from "PRODUCT"."TABLE_A" where P_NO=88118811;

當然這些動作按照以往的經驗都是正確的，但那該死的full table scan就是出來了，使用SQL_Trace也是看到query有幾百的數值，兩個人很好笑的在那邊發呆也找不出個所以然的解決方法，所幸跟他要了他create table的語句，打算回家測試看看。當create table語句寄來一看，唉~~~真是個天才。



create table "PRODUCT"."TABLE_A" (

..

P_NO VARCHAR2(20)

..




where P_NO=88118811 是以數值型態去撈資料，但是P_NO是以字元型態存入資料庫的，select語句不改當然會發生這樣的糗事，修改了一下之後就沒問題了。

select * from "PRODUCT"."TABLE_A" where P_NO='88118811';

再次的SQL_TRACE就可以看到Query數值在個位數了。



這就應證了我們同事之前常流傳的一句話  "這種該死的問題，他的癥結點一定在一個很白痴的地方，只是我們都還沒找到"