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

樣例問(wèn)題

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

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

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

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

第一原則

對(duì)我來(lái)說(shuō)，相比于編寫清晰易讀的SQL，從SQL得到正確的結(jié)果才是第一要?jiǎng)?wù)。我要做的第一件事就是編寫下面的SQL語(yǔ)句來(lái)獲取客戶總數(shù)。在我寫完整個(gè)語(yǔ)句之后我會(huì)再調(diào)整它。

我寫的第一個(gè)語(yǔ)句是這樣的：

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

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

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

格式化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 

總是使用表別名

時(shí)間會(huì)證明這么做是有必要的。如果你沒(méi)有對(duì)SQL語(yǔ)句中用到的每個(gè)字段使用別名，在將來(lái)某個(gè)時(shí)候可能會(huì)給這個(gè)查詢語(yǔ)句添加進(jìn)來(lái)別的同名字段。到那時(shí)候你的查詢乃至報(bào)表就會(huì)產(chǎn)生錯(cuò)誤(出現(xiàn)了重名字段名)。

逗號(hào)放到字段之前

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

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

把“JOIN”放到獨(dú)立行

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

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

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

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

列模式編輯

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

創(chuàng)建全部索引

在使用字段較多的UNION語(yǔ)句時(shí)：

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

測(cè)試查詢結(jié)果

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

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

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