1 衡量table筆數，以便拆解statement時選擇適當的順序來執行
2 拆解statement，利用sub query的方式
，可分段check response time找出效能缺口
在8i之後在select,from,where後均可加入sub query
重點在於先將筆數多的table拆解出來。
tune完整段仍有問題時，則應檢查index、或是where部分是否仍為效能缺口
3 針對where條件欄位加入index or 移除不必要的index
4 使用Hint,透過Hint可強迫DB在執行各項Query時採用特定的方式，
不過似乎並無特定的rule可尋，只能依經驗或靠tuning tool來協助
找出最佳解。
EX: select /*+ first_rows */ name,department from dept;
5 check index
check fragmentation(類似硬碟重整)
adjust chain row(用以調整一次抓取資料的Block範圍)
6 不能以null作索引，任何包含null值的列都將不會被包含在索引中。
也就是說如果某列存在空值，即使對該列建索引也不會提高效能。
7 避免萬用字元%在搜尋字首出現，因會導致Oracle無法以此欄位建索引。
在很多情況下可能無法避免這種情況，
但是一定要心中有底，萬用字元的使用會降低效能。
通用原則：
1 not in比in費時(避用)若要用則應改寫為NOT EXISTS子句
同樣的在Oracle中幾乎可將所有的IN操作符子查詢改寫為使用EXISTS。
2 distinct、order by費時(應拆解至細部sub query，避免擺至最外層)
3 要避免直接對driven table作運算
例：where to_char(date,’yyyy/mm/dd’)=’2003/07/02’
應改為：date = to_date(’2003/07/02’,’yyyy/mm/dd’)較有效率
4 若比對條件式中含有常數，則應將此段query擺在前頭
補充:
1 雖然用Hint 可快速解決當下Sql 速度慢的問題.但須經常重新Tuing,
因為一段時間之後,Table 的筆數增長各有不同.
所以時間久了,原本可改善的Rule 反而不管用.
2 增加Index 並非萬能,因為多增Index 會影響Table
在執行 DML (Insert/Update/Delete) 的時間.
3 在 Oracle 的 Performance & Tuing 裡,
除了Sql 下的好不好以外, DB 的參數設定值亦是關鍵.
