背景

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

樣例問題

下面是一個典型的SQL應用場景，業務報表的數據來自三張表，客戶表、銷售表和地域表。基于2015年一月份的數據，該報表需要展示在每個行政區內的客戶總數和銷量總數。該需求通過一個簡單的SQL語句就可以實現，需要關聯查詢三張表。

數據可能出現的問題

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

• 數據可能來自不同的數據源。也就是說你不能保證這幾個表之間的完整性。具體舉例來說，你不能假定客戶表中所有的郵政編碼都是有效的郵政編碼，并且一定在地域表中存在。
• 錄入客戶表數據的應用可能捕獲到未經驗證的地點數據，可能會包括錯誤的郵政編碼。
• 郵政編碼表可能不是完整的。新發布的郵政編碼可能沒有在發布后及時導入到表中。

 

 

 

***原則

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

我寫的***個語句是這樣的：

SELECTCOUNT(DISTINCT cust_id) as count_customersFROMcustomers 
 
Result: 
 
count_customers 
 
“10” 

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

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

格式化SQL

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

SELECT 
 
0 
 
,c.cust_post_code 
 
,p.location 
 
,COUNT(DISTINCT c.cust_id) number_customers 
 
,SUM(s.total_amount) as total_sales 
 
FROM 
 
customers c 
 
JOIN post_codes p ON c.cust_post_code = p.post_code 
 
JOIN sales s ON c.cust_id = s.cust_id 
 
WHERE 
 
1=1 
 
AND s.sales_date BETWEEN ‘2015-01-01’ AND ‘2015-01-31’ 
 
—AND s.order_id = 5 
 
GROUP BY 
 
c.cust_post_code 
 
,p.location 

總是使用表別名

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

逗號放到字段之前

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

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

把“JOIN”放到獨立行

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

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

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

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

列模式編輯

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

創建全部索引

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

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

 

測試查詢結果

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

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對我來說意味著我必須寫獨立的測試來檢查數據。通過注釋掉的那幾行語句我可以使用***原則驗證我查詢數據的準確性。這么做提高了我的效率和報表的準確性。

原文鏈接：http://www.searchdatabase.com.cn/showcontent_88809.htm