5個讓DBA愛上你的SQL技巧

我的一個同事Martin Masarik，SQLde的CEO，跟我談起了他的一個DBA朋友，他管理著一個國際銀行的Oracle數據庫，數據規模約2TB。Martin Masarik曾問他：“什么樣的SQL問題能讓你氣憤到豎起頭發？”，他總結了以下幾點，都是經驗之談：

一、不要在索引列上調用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
翻譯作者：碼農網 – 小峰