一、不要在索引列上呼叫Function
這樣做將會阻止資料庫使用這個索引，這個問題甚至可以影響這個分割槽表，因為這樣做的話將不會從指定的分割槽中讀取資料，而是掃描整一個表空間。對於大資料量的資料表，這將是效能上的一場大災難。
不要這樣做：
WHERE TIME_ID+14 > to_number(to_char(sysdate,'J'))應該這樣做：
WHERE TIME_ID > to_number(to_char(sysdate-14,'J'))
二、使用Analyze對複雜SQL的優化
如果你不這樣做，將意味著：你拒絕使用資料庫的查詢優化器，也失去了使用優化連線的機會。假設你建立了一張擁有100萬條記錄的臨時表，如果不對其進行分析，那麼優化器將無法從現有的線索中獲取表中真正的內容，於是它只能決定使用巢狀迴圈連線來一行行地掃描資料表，如果資料量不大，可能我們感覺不到效能的損失，但是隨著資料集的增長，你的資料庫效能會越來越差。
建議這樣做：
ANALYZE TABLE <TABLE_NAME> COMPUTE STATISTICS
三、將複雜的SQL分成幾步執行
把SQL想象成披薩，我想你應該不會一下子將整個披薩吞到嘴裡嚼爛它吧。
對於建立一個複雜的SQL查詢，我們最好將其分成3-4個步驟，SQL越簡單，優化器的效果就越好，另外，對每一張資料表中的資料也越容易除錯。
四、只有在必要的時候才使用Distinct
這是一個非常好的經驗法則，Distinct經常被用在返回2條或2條以上重複記錄的SQL查詢中，使用Distinct，將會過濾掉重複的資料記錄。但是使用Distinct的目的一定要明確，當你確定返回的記錄一定是唯一的時候才能使用，比如使用者id。濫用Distinct將會出現不可預知的錯誤，比如多表連線查詢的情況。
五、合理建立索引
最後一點就是合理建立表索引，簡單來說，假如有一張10萬條記錄的資料表，你可能經常會查詢這樣的資訊：“我的某個客戶資訊在這張表中嗎？”。如果使用了索引，那麼檢索這條客戶資訊將非常迅速，否則資料庫優化器將會選擇全表掃描，這在大資料量的情況下簡直就是噩夢。
譯文連結：http://www.codeceo.com/article/5-sql-tips-dba-love-you.html
英文原文：5 Tips for writing efficient SQL queries that get you some DBA love
來自：碼農網
相關閱讀
評論(1)