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萬條記錄的資料表，你可能經常會查詢這樣的資訊：“我的某個客戶資訊在這張表中嗎？”。如果使用了索引，那麼檢索這條客戶資訊將非常迅速，否則資料庫優化器將會選擇全表掃描，這在大資料量的情況下簡直就是噩夢。