SQL语言最佳实践
為單位制訂的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 子句的執行進程會在找到值后?？?#xff0c;而 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是一種非常靈活的語言，提供了多種方法在數據庫上執行所需的任務。在編程中，性能瓶頸大多來自數據庫操作和響應。以上這些建議，可能有效地幫助加快性能，消除不必要的延時，并可避免長期積累的數據庫問題。
喜歡就來個三連，讓更多人因你而受益
總結
- 上一篇： 那些被.NET大厂拒绝的大佬们，究竟弱在
- 下一篇： 一次Redis client组件性能分析