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

樣例問題

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

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

雖然SQL很簡單，但保證你的結(jié)果正確仍然是真正的關(guān)鍵，因?yàn)橛邢旅嬉恍┰蚩赡軐?dǎo)致錯誤：

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

第一原則

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

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

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

這個查詢很重要，因?yàn)樗o緊圍繞第一原則。因?yàn)闆]有SQL管理查詢，也就沒有依賴，我知道這就是客戶數(shù)量的正確結(jié)果。我把這個結(jié)果記下來，因?yàn)槲铱傂枰眠@個數(shù)字來衡量后面的SQL(是否正確)，在本文后面也會多次提到。

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

格式化SQL

下面就是根據(jù)我的格式化思路推薦的格式化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語句中用到的每個字段使用別名，在將來某個時候可能會給這個查詢語句添加進(jìn)來別的同名字段。到那時候你的查詢乃至報(bào)表就會產(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”放到獨(dú)立行

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

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

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

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

列模式編輯

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

創(chuàng)建全部索引

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

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

測試查詢結(jié)果

我必須使用外連接“OUTER”列出所有客戶，因?yàn)椴皇撬锌蛻舻泥]政編碼都在地域表里有相應(yīng)的郵政編碼。我可以通過包含和排除不同字段和表反復(fù)操作來確保我查詢的結(jié)果與最開始那個查詢(單獨(dú)查詢客戶的那個語句)結(jié)果相同，這其實(shí)是對第一原則的遵守。

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對我來說意味著我必須寫?yīng)毩⒌臏y試來檢查數(shù)據(jù)。通過注釋掉的那幾行語句我可以使用第一原則驗(yàn)證我查詢數(shù)據(jù)的準(zhǔn)確性。這么做提高了我的效率和報(bào)表。

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

最新評論