為單位制訂的SQL規范，分享一下。

?

首先說一下，這是公司用的一個規范，給到程序員做參考的。

其實，這個規范是建立在對SQL有一定熟悉程序的基礎上的，所以規范本身并不涉及SQL語法學習的相關內容。

?

1. 絕對避免使用 SELECT *

SELECT * 查詢會返回所有列的記錄。這樣的查詢會有很多問題：

• 很多情況不需要檢索所有的字段，使用 SELECT * 會消耗過多的帶寬；

• 在考慮到修改表結構的前題并存在臟數據的情況，SELECT * 出現意想不到的結果；

• SELECT * 比 SELECT [字段] 要慢，因為后者可以使用列索引；

• SELECT * 返回的列順序不可控。

因此，要求查詢時逐個列表需要查詢的字段。包括查詢全部字段，也需要將字段逐個寫出來，并按照需要的方式排序字段的先后次序。

2. 區分使用 WHERE 和 HAVING

SQL 中 WHERE 和 HAVING 從語法上可以在一定范圍內混著用，但兩個詞的語義截然不同，在實際編程時，需要按語義分開使用。

• WHERE 用于全部CRUD，HAVING只用于查詢 SELECT；

• WHERE 用在聚合操作之前過濾數據，HAVING 用在聚合之后；

• HAVING 子句中可以使用聚合函數，如SUM、MIN、MAX、COUNT，而 WHERE 子句不能使用聚合函數，除非該子句是 HAVING 子句中包含的子查詢的一部分。

3. 表連接查詢使用 INNER JOIN

JOIN 是使用非常多的SQL查詢之一，允許用戶從多個表中選擇數據。WHERE 也可以連接兩個表并獲取聚合數據，但開發中禁止使用。

一個主要的原因是 WHERE 返回的是 CROSS JOIN，返回的記錄數是兩個表記錄的乘積。例如兩個表A和B，各有1000條數據，用 WHERE 子句，將會返回一個 1000 x 1000 = 1000000條記錄的 CROSS JOIN，然后再從這個數據集里提取滿足條件的數據。這在性能上不可接受。

而上面的例子，在 INNER JOIN 時僅返回 1000 條記錄，然后從這個數據集中提取滿足條件的數據。

雖然有些數據庫會在內部將 JOIN 查詢中的 WHERE 轉換為 INNER JOIN，但規則要求顯式使用 INNER JOIN，而不是 WHERE。

4. 使用 EXISTS 和 NOT EXISTS 代替 IN 和 NOT IN

在檢索某個值在表中存在與否時，EXISTS 子句的執行進程會在找到值后停卡，而 IN 子句會在找到值后繼續掃描所有的值。

NOT EXISTS 和 NOT IN 的執行也一樣。

這個規則也是性能原因。

5. 使用 = 代替 LIKE

兩個方式都可以用來匹配字符串，但 LIKE 用于匹配通配符，而 = 用來進行精確匹配。

在 SQL 中，= 操作符可以使用索引，會比 LIKE 更快。

6. 使用 LIMIT 子句限制檢索結果數量

查詢數據時，盡可能使用 LIMIT 子句，來限制查詢結果數量。大多數情況下，查詢沒有必要返回所有行。限制查詢返回的數量，也可以提高查詢性能。

7. 查詢多表時使用表別名

多表查詢時，使用表別名，避免混淆，并防止數據庫在搜索列表所屬的表時解析列名。這不會增加工作量，但很有效。

8. 避免使用 “sp_” 作為存儲過程的名稱前綴

原則上，避免使用存儲過程。

如果必須使用存儲過程，那必須禁止使用?sp_?作為前綴的存儲過程名稱。SQL Server 中，會首先在主數據庫中查詢名稱以?sp_?開頭的存儲過程，然后再搜索其它地方。因此，避免?sp_?打頭的存儲過程名稱可以節省大量時間，SQL Server將直接檢查 DBO 作為存儲過程的所有者，而不是在主數據庫中查找存儲過程。

9. 采用規范的查詢代碼風格

這算是一個建議，但是，使用良好規范的代碼風格是必要的：

• 完整的注釋。需要幫助其它團隊成員理解查詢的目的，并提醒開發者做的是什么；

• 使用明顯的命名約定。數據庫、表名、字段名，包括臨時表和變量名都應該是可讀和清楚的；

• 盡可能縮進查詢語句。通過縮進來確保清晰的代碼外觀，并提高查詢的可讀性。

SQL是一種非常靈活的語言，提供了多種方法在數據庫上執行所需的任務。在編程中，性能瓶頸大多來自數據庫操作和響應。以上這些建議，可能有效地幫助加快性能，消除不必要的延時，并可避免長期積累的數據庫問題。

喜歡就來個三連，讓更多人因你而受益

總結

以上是生活随笔為你收集整理的SQL语言最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。