一、不要在索引列上調用Function
這樣做將會阻止資料庫使用這個索引，這個問題甚至可以影響這個分區表，因為這樣做的話將不會從指定的分區中讀取數據，而是掃描整一個表空間。對於大數據量的資料表，這將是效能上的一場大災難。
應該這樣做：
WHERE
TIME_ID+14 > to_number(to_char(sysdate,'J'))
登入後複製
二、使用Analyze對複雜SQL的最佳化
二、使用Analyze對複雜SQL的最佳化
如果你不這樣做，將意味著你拒絕使用的查詢優化連線的機會。假設你建立了一張擁有100萬筆記錄的臨時表，如果不對其進行分析，那麼優化器將無法從現有的線索中獲取表中真正的內容，於是它只能決定使用嵌套循環連接來一行行地掃描資料表，如果資料量不大，可能我們感覺不到效能的損失，但是隨著資料集的成長，你的資料庫效能會越來越差。
建議這樣做：
WHERE
TIME_ID > to_number(to_char(sysdate-14,'J'))
登入後複製
三、將複雜的SQL分成幾步執行
把SQL想像成披薩，我想你應該不會一下子將整個披薩吞到嘴裡嚼爛它吧。
對於建立一個複雜的SQL查詢，我們最好將其分成3-4個步驟，SQL越簡單，優化器的效果就越好，另外，對每一張資料表中的資料也越容易調試。
四、只有在必要的時候才使用Distinct
這是一個非常好的經驗法則，Distinct經常被用在返回2條或2條以上重複記錄的SQL查詢中，使用Distinct，將會過濾掉重複的數據記錄。但使用Distinct的目的一定要明確，當你確定回傳的記錄一定是唯一的時候才能使用，例如使用者id。濫用Distinct將會出現不可預測的錯誤，例如多表連線查詢的情況。
五、合理創建索引
最後一點就是合理創建表索引，簡單來說，假如有一張10萬條記錄的數據表，你可能經常會查詢這樣的信息：“我的某個客戶信息在這張表中嗎？如果使用了索引，那麼檢索這條客戶資訊將非常迅速，否則資料庫優化器將會選擇全表掃描，這在大數據量的情況下簡直就是噩夢。
