在本文中,作者將分享如何通過格式良好的SQL語句提升生產(chǎn)率，感興趣的小伙伴們可以參考一下

格式良好的SQL并不會比亂七八糟的SQL運行效果更好。數(shù)據(jù)庫其實不怎么關心SQL語句中你把逗號放到了字段名的前面還是后面。為了你自己思路清楚，應該做一個有效率的SQL編寫者，我建議你遵守以下這些格式規(guī)則。在本文中我將分享如何通過格式良好的SQL語句提升生產(chǎn)率。我定義的效率指的是能從SQL 輸出準確的結果，并且代碼清晰易于理解、修改和調(diào)試。我只列出了“SELECT”語句，因為我寫的SQL語句99%都是查詢語句。格式化SQL代碼是非常個性化的事，我也很清楚因人而異，開發(fā)者都認為自己的格式化規(guī)則是最合理的。

樣例問題

下面是一個典型的SQL應用場景，業(yè)務報表的數(shù)據(jù)來自三張表，客戶表、銷售表和地域表。基于2015年一月份的數(shù)據(jù)，該報表需要展示在每個行政區(qū)內(nèi)的客戶總數(shù)和銷量總數(shù)。該需求通過一個簡單的SQL語句就可以實現(xiàn)，需要關聯(lián)查詢?nèi)龔埍怼?/p>

數(shù)據(jù)可能出現(xiàn)的問題

雖然SQL很簡單，但保證你的結果正確仍然是真正的關鍵，因為有下面一些原因可能導致錯誤：

數(shù)據(jù)可能來自不同的數(shù)據(jù)源。也就是說你不能保證這幾個表之間的完整性。具體舉例來說，你不能假定客戶表中所有的郵政編碼都是有效的郵政編碼，并且一定在地域表中存在。

錄入客戶表數(shù)據(jù)的應用可能捕獲到未經(jīng)驗證的地點數(shù)據(jù)，可能會包括錯誤的郵政編碼。

郵政編碼表可能不是完整的。新發(fā)布的郵政編碼可能沒有在發(fā)布后及時導入到表中。

第一原則

對我來說，相比于編寫清晰易讀的SQL，從SQL得到正確的結果才是第一要務。我要做的第一件事就是編寫下面的SQL語句來獲取客戶總數(shù)。在我寫完整個語句之后我會再調(diào)整它。

我寫的第一個語句是這樣的：

1. SELECTCOUNT(DISTINCT cust_id) as count_customersFROMcustomers  
2.  
3. Result:  
4.  
5. count_customers  
6.  
7. “10”  

這個查詢很重要，因為它緊緊圍繞第一原則。因為沒有SQL管理查詢，也就沒有依賴，我知道這就是客戶數(shù)量的正確結果。我把這個結果記下來，因為我總需要拿這個數(shù)字來衡量后面的SQL(是否正確)，在本文后面也會多次提到。

下一步要做的事就是添加必要的字段和表完成查詢。我特意把“添加”這個詞高亮標注出來，因為根據(jù)我的規(guī)則，我會在應用第一原則時把能獲取相同結果的查詢注釋掉。下面就是我最終格式化的查詢語句。

格式化SQL

下面就是根據(jù)我的格式化思路推薦的格式化SQL。

1. SELECT 
2.  
3. 0  
4.  
5. ,c.cust_post_code  
6.  
7. ,p.location  
8.  
9. ,COUNT(DISTINCT c.cust_id) number_customers  
10.  
11. ,SUM(s.total_amount) as total_sales  
12.  
13. FROM 
14.  
15. customers c  
16.  
17. JOIN post_codes p ON c.cust_post_code = p.post_code  
18.  
19. JOIN sales s ON c.cust_id = s.cust_id  
20.  
21. WHERE 
22.  
23. 1=1  
24.  
25. AND s.sales_date BETWEEN ‘2015-01-01' AND ‘2015-01-31' 
26.  
27. —AND s.order_id = 5  
28.  
29. GROUP BY 
30.  
31. c.cust_post_code  
32.  
33. ,p.location  

總是使用表別名

時間會證明這么做是有必要的。如果你沒有對SQL語句中用到的每個字段使用別名，在將來某個時候可能會給這個查詢語句添加進來別的同名字段。到那時候你的查詢乃至報表就會產(chǎn)生錯誤(出現(xiàn)了重名字段名)。

逗號放到字段之前

在調(diào)試或者測試我的查詢語句時，這么做可以方便地注釋掉某個字段，而不需要修改其它行，所有的逗號都沒有缺少或多余。不這么做的話你可能總要調(diào)整逗號才能保證語句正確。如果你經(jīng)常要調(diào)試語句，這么做會帶來極大方便，效率會更高。這個做法對“SELECT”部分和“GROUP BY”子句部分同樣適用。

在開發(fā)時我使用“SELECT 0”作為語句的開始，遷移到正式環(huán)境時它很容易刪除掉。這樣我們就可以在后面所有字段前面都寫都好了。沒有這個“0”的話，如果我想注釋掉第一個字段(本例中是“c.cust_post_code”)，我就必須處理后面的逗號問題。我必須臨時注釋掉它，將來還要加回來。在“GROUP BY”語句中也是一樣的。這個“0”是額外加的。

把“JOIN”放到獨立行

好處

把“JOIN”語句放到獨立行有以下：

這么做很容易看到本查詢語句涉及的所有表，只需要看滾動“JOIN”語句就可以了。

使用“JOIN”相比于在“WHERE”子句中列出所有表和表達式關系，可以把所有邏輯關系都放到一個地方。我們不可能總是吧“JOIN”語句放到一行中，但是至少應該放到一起。

這么做的話要注釋掉“JOIN”語句也是相對容易的。這在調(diào)試時非常有用，你可能需要知道是否是“JOIN”引起了數(shù)據(jù)問題。

列模式編輯

在處理大量字段的情況時，列模式編輯非常方便。下面是我曾經(jīng)做過的第一個動態(tài)GIF展示，你可以注釋掉所有非聚集字段。我使用了列模式編輯，而不僅僅是注釋掉字段：

創(chuàng)建全部索引

在使用字段較多的UNION語句時：

注釋掉“GROUP BY”子句的字段清單

測試查詢結果

我必須使用外連接“OUTER”列出所有客戶，因為不是所有客戶的郵政編碼都在地域表里有相應的郵政編碼。我可以通過包含和排除不同字段和表反復操作來確保我查詢的結果與最開始那個查詢(單獨查詢客戶的那個語句)結果相同，這其實是對第一原則的遵守。

1. SELECT0,c.cust_post_code—,p.location,COUNT(DISTINCT c.cust_id) number_customers,SUM(s.total_amount) as total_salesFROMcustomers c—LEFT OUTER JOIN post_codes p ON c.cust_post_code = p.post_codeJOIN sales s ON c.cust_id = s.cust_idWHERE1=1AND s.sales_date BETWEEN ‘2015-01-01' AND ‘2015-01-31'—AND c.cust_post_code = 2000—AND p.post_code = 200GROUP BYc.cust_post_code—,p.location  

像這樣的SQL對我來說意味著我必須寫獨立的測試來檢查數(shù)據(jù)。通過注釋掉的那幾行語句我可以使用第一原則驗證我查詢數(shù)據(jù)的準確性。這么做提高了我的效率和報表。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助。