已格式化的SQL并不比未格式化SQL運(yùn)行地更快。數(shù)據(jù)庫可能真的不太在意你是否把逗號(hào)放在每個(gè)字段名稱的前面或后面。為幫助你更理智和成為一名高效的SQL編寫者，我建議你遵循一些格式化的指導(dǎo)方針。在這篇文章里，我將分享如何格式化SQL語句來提高工作效率。我對(duì)生產(chǎn)力這樣定義，能夠從SQL得到準(zhǔn)確的結(jié)果，同時(shí)代碼容易理解，修改和調(diào)試。我只會(huì)專注于SELECT語句，它占到我編寫SQL的99%。格式化SQL代碼是非常個(gè)性的選擇，我很清楚，不同的人將鐘愛他們自己的格式化規(guī)則。

問題樣例

這是一個(gè)典型的SQL使用場景，業(yè)務(wù)上需要這樣的報(bào)表，它的數(shù)據(jù)在三個(gè)表中，分別是customer、sales 和 location。在2015年1月，報(bào)表需要顯示位于每一個(gè)郵政編碼區(qū)域的客戶數(shù)量和總銷售額。這應(yīng)該是一個(gè)簡單的SQL語句，它連接三個(gè)表。

數(shù)據(jù)可能有問題

雖然SQL很容易，確保結(jié)果準(zhǔn)確才是真正的挑戰(zhàn)，以下是許多可能的原因中的一個(gè)，包括:

數(shù)據(jù)可能來自不同數(shù)據(jù)源。這意味著在不同的表中的無法保證引用完整性。簡單說，你不能假定 customer 表上的所有郵政編碼是有效的，同時(shí)在 location 表上也存在該問題。存取客戶數(shù)據(jù)的應(yīng)用程序，可能沒有適當(dāng)?shù)臄?shù)據(jù)驗(yàn)證?？赡芤呀?jīng)存入不正確的郵政編碼。postcode 表可能沒有所有郵政編碼。新的郵政編碼代碼可能被引入，但自從上次更新還沒有添加到表中。

第一原則

對(duì)我來說，格式化SQL更多地是從SQL獲得正確的結(jié)果，因?yàn)樗忻鞔_的SQL，很容易跟蹤。我做的第一件事編寫獲取客戶總數(shù)的語句。這是個(gè)數(shù)字，我將在寫完整個(gè)語句后進(jìn)行對(duì)比。

我寫的第一條語句是：

SELECT
???COUNT(DISTINCT?cust_id)?AS?count_customers
FROM
????????customers

Result:

“10″

這個(gè)查詢很重要，因?yàn)樗裱?第一原則(外部鏈接)?。因?yàn)闆]有SQL連接，因此沒有依賴，我知道這是正確的客戶數(shù)量。我總是記下結(jié)果，因?yàn)槲铱偸切枰眠@個(gè)數(shù)字對(duì)比，在這篇文章是 10。

接下來我要做的就是添加必要的字段和表到這個(gè)查詢。我強(qiáng)調(diào)添加這個(gè)詞，因?yàn)楦鶕?jù)我遵循的格式化規(guī)則，我可以注釋掉查詢的元素來得到和我應(yīng)用第一原則時(shí)相同的結(jié)果。下面是我最終的格式化查詢，使用格式化查詢的方式。

格式化SQL

下面是我推薦的格式化的SQL，緊接后面是我進(jìn)行的格式化選擇的理由。

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

總是使用表別名

這將會(huì)在你的SQL中得到證實(shí)。如果你不為參與查詢的每個(gè)字段使用?別名(外部鏈接)?，有時(shí)候在后期，具有相同名稱的字段添加到查詢中使用的某個(gè)表中。你的查詢和你的報(bào)表將出現(xiàn)一個(gè)錯(cuò)誤(發(fā)現(xiàn)重復(fù)的字段名)。

逗號(hào)在字段前

當(dāng)調(diào)試/測試我的查詢時(shí)，這讓我能輕易進(jìn)行字段注釋和取消注釋，不需要在查詢中修改任何其他行，以確保逗號(hào)在正確的地方。我看過一些文章，博主為了大事化小不得不改變另一個(gè)查詢的一部分，以確保逗號(hào)是正確的，但是你如果花大部分時(shí)間編寫和測試 SQL 語句，這是一個(gè)大問題。你按這種方式將會(huì)更有效率。這個(gè)在 SELECT 和 GROUP BY 查詢部分都工作地很好。

我在開發(fā)環(huán)境使用 SELECT 0，同時(shí)傾向于進(jìn)入生產(chǎn)環(huán)境之前刪除它。它允許我把逗號(hào)放在所有字段前。如果沒有 0，我想注釋掉c.cust_post_code，它是第一個(gè)字段，我就必須注釋掉第二個(gè)字段前面的逗號(hào)。我也會(huì)在 GROUP BY 子句做同樣的事情。0 可以消除這個(gè)額外的工作。

在新的一行JOIN

將JOIN語句放在一個(gè)新行的優(yōu)勢包括：

通過僅僅向下滾動(dòng)JOIN語句列表就可以很容易地查看查詢中所涉及到的所有表。使用 JOIN，相比將所有表和關(guān)系表達(dá)式都列在 WHERE 語句中，它可以將所有關(guān)系邏輯保持在一個(gè)地方。JOIN 語句也許不可能總是遵循在一行，但至少會(huì)在一個(gè)地方。注釋掉 JOIN 會(huì)相對(duì)比較容易。在調(diào)試時(shí)，當(dāng)你想知道哪個(gè) JOIN 導(dǎo)致數(shù)據(jù)差異時(shí)，將很有用。列模式編輯

在處理大量的字段時(shí)，列模式編輯非常方便。下面是我的第一次動(dòng)畫GIF展示，顯示你如何注釋掉所有非聚合字段。在實(shí)踐中我使用

列模式編輯(外部鏈接)，不僅僅是注釋字段還包括:

大量創(chuàng)建索引在使用 UNION 語句時(shí)帶有長的字段列表注 釋GROUP BY 子句長的字段列表

測試查詢結(jié)果

我不得不使用外連接來列出所有客戶，因?yàn)椴⒉皇撬锌蛻舻泥]政編碼在 location 表中都能找到對(duì)應(yīng)郵政編碼。我能夠做到這一點(diǎn)，通過在我的查詢中反復(fù)包括和排除不同的字段和表，確保我能夠與基于第一原則的最早查詢保持一致。

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
???--LEFT?OUTER?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?c.cust_post_code?=?2000
???--AND?p.post_code?=?200
GROUP?BY
????c.cust_post_code
???--,p.location

對(duì)我來說，像這樣格式化SQL，意味著我不必編寫為了檢查數(shù)據(jù)做單獨(dú)的測試。通過注釋掉一些行，我能使用第一原則來測試數(shù)據(jù)的準(zhǔn)確性。這可以提高我的效率，以及報(bào)表的準(zhǔn)確性。