最佳化scenarios

1. 外來鍵的列沒加索引，當對主表鍵進行DML, 會鎖住整個子表。...........................[@more@] Normal 0 false false false MicrosoftInternetExplorer4 1. 外來鍵的列沒加索引，當對主表鍵進行DML, 會鎖住整個子表。

2. 索引失效，如where lower(name)=’ssss’, name上的索引會失效。 或者隱式的資料型別轉換：where item_id=12345, 這裡item_id是varchar2, 就會先隱式的轉換成數字型，索引失效了。

3. PLSQL裡的程式給臨時錶轉載了很多資料，但在程式裡沒有對錶進行分析，oracle走了錯誤的表連線，本來該用hash_join, 用了nested_loop, 嚴重影響效能。

4. 重新設計索引，可考慮把查詢中經常用到的列加到索引中，oracle掃描時就會只掃描index: full index scan,不用掃描資料段了。

5. PLSQL裡的多表複雜連線，拆分成幾個小的連線，用上臨時表儲存中間資料。

6. 表的設計問題，example:

三張表幾乎都幾千萬行, 找出在ITEM表裡的但沒存在LINK, ITEM_LINK 裡已經連結好了的ITEM_ID, 下面第一種方法是傳統方法,用not exists直觀, 第二種是用左外連線. 但從兩種方法看效率都不高, 都要大量的連線,要nested loop. 也許修改表結構是最好的選擇了,給ITEM表加個欄位,如LINK_STATUS, 在ITEM_LINK,LINK已經link了,就給這個欄位置位.以後再來判斷就不需要用not exists來判斷是否在LINK,ITEM_LINK表裡已link了!

(本來要跑10分鐘，加了status欄位後，30秒。)

7. 找出效能低效的SQL語句：

select ELAPSED_TIME,EXECUTIONS,FIRST_LOAD_TIME,ELAPSED_TIME/decode(executions,0,1,executions)/1000000/60 "Mins", sql_text from V$SQL where module='JDBC Thin Client' order by 4 desc

Normal 0 false false false MicrosoftInternetExplorer4

Normal 0 false false false MicrosoftInternetExplorer4

Continue….