本文由伯樂在線-cucr翻譯，黃利民校稿。未經許可，禁止轉載！英文出處：msiman.ga。歡迎加入翻譯小組。

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

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

雖然SQL很容易，確保結果準確才是真正的挑戰，以下是許多可能的原因中的一個，包括:

• 數據可能來自不同數據源。這意味著在不同的表中的無法保證引用完整性。簡單說，你不能假定 customer 表上的所有郵政編碼是有效的，同時在 location 表上也存在該問題。
• 存取客戶數據的應用程序，可能沒有適當的數據驗證。可能已經存入不正確的郵政編碼。
• postcode 表可能沒有所有郵政編碼。新的郵政編碼代碼可能被引入，但自從上次更新還沒有添加到表中。

對我來說，格式化SQL更多地是從SQL獲得正確的結果，因為它有明確的SQL，很容易跟蹤。我做的第一件事編寫獲取客戶總數的語句。這是個數字，我將在寫完整個語句后進行對比。

我寫的第一條語句是：

Result:

這個查詢很重要，因為它遵循了第一原則(外部鏈接)。因為沒有SQL連接，因此沒有依賴，我知道這是正確的客戶數量。我總是記下結果，因為我總是需要拿這個數字對比，在這篇文章是 10。

接下來我要做的就是添加必要的字段和表到這個查詢。我強調添加這個詞，因為根據我遵循的格式化規則，我可以注釋掉查詢的元素來得到和我應用第一原則時相同的結果。下面是我最終的格式化查詢，使用格式化查詢的方式。

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

這將會在你的SQL中得到證實。如果你不為參與查詢的每個字段使用別名(外部鏈接)，有時候在后期，具有相同名稱的字段添加到查詢中使用的某個表中。你的查詢和你的報表將出現一個錯誤(發現重復的字段名)。

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

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

將JOIN語句放在一個新行的優勢包括：

• 通過僅僅向下滾動JOIN語句列表就可以很容易地查看查詢中所涉及到的所有表。
• 使用 JOIN，相比將所有表和關系表達式都列在 WHERE 語句中，它可以將所有關系邏輯保持在一個地方。JOIN 語句也許不可能總是遵循在一行，但至少會在一個地方。
• 注釋掉 JOIN 會相對比較容易。在調試時，當你想知道哪個 JOIN 導致數據差異時，將很有用。

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

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

• 大量創建索引
• 在使用 UNION 語句時帶有長的字段列表
• 注 釋GROUP BY 子句長的字段列表

我不得不使用外連接來列出所有客戶，因為并不是所有客戶的郵政編碼在 location 表中都能找到對應郵政編碼。我能夠做到這一點，通過在我的查詢中反復包括和排除不同的字段和表，確保我能夠與基于第一原則的最早查詢保持一致。

對我來說，像這樣格式化SQL，意味著我不必編寫為了檢查數據做單獨的測試。通過注釋掉一些行，我能使用第一原則來測試數據的準確性。這可以提高我的效率，以及報表的準確性。