本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)。

據(jù)2020年JetBrains開發(fā)者生態(tài)系統(tǒng)調(diào)查顯示，有56%的開發(fā)者在開發(fā)中使用SQL數(shù)據(jù)庫或與SQL數(shù)據(jù)庫進行交互。但即便如此，大多數(shù)開發(fā)人員仍將SQL概念視為第二選擇，他們通常通過自己選擇的語言進行交互，而且在設(shè)計中作用不大。總而言之，能夠連接并運行基本查詢就足夠了。

許多公司甚至還有一個獨立的數(shù)據(jù)庫團隊，負責(zé)數(shù)據(jù)庫的設(shè)計和優(yōu)化。筆者認為這是限制人們更深入地學(xué)習(xí)SQL的原因：很多人是這樣想的，SQL是別人使用的工具。軟件開發(fā)人員的工具夠多了。

但這個行業(yè)技多不壓身，你永遠不知道接下來遇到什么狀況。我們每天都與SQL進行交互，因此，儲備更多的知識有備無患。此外，如果所在的公司規(guī)模小、沒有足夠的數(shù)據(jù)庫團隊資源，那么你的責(zé)任將更大。在面試中展現(xiàn)出你對數(shù)據(jù)庫使用技巧很自信，會帶你通往許多有趣的職業(yè)方向。

相比較其他領(lǐng)域而言筆者更喜歡SQL開發(fā)。我早期的實習(xí)就是與一群杰出的數(shù)據(jù)庫管理員共事，從此愛上SQL。筆者在學(xué)校上過數(shù)據(jù)庫課程，因此有一些基本知識，但在實習(xí)期間學(xué)到的東西是無價的，不僅讓我意識到自己對數(shù)據(jù)的熱情，期間收獲的技術(shù)理解也為之后的每項工作大大增色。

數(shù)據(jù)庫開發(fā)和管理內(nèi)容很多，相關(guān)專家也是妙筆生花，這些可以幫助開發(fā)人員(不會靈活運用SQL)在涉及到SQL知識時脫穎而出。根據(jù)筆者經(jīng)驗，本文中的概念引用自Microsoft SQL Server，這些概念也適用于其他SQL數(shù)據(jù)庫管理系統(tǒng)。

規(guī)范化

如果你在學(xué)校選修過關(guān)系數(shù)據(jù)庫的課程，那你肯定見過“規(guī)范化”一詞。這是數(shù)據(jù)庫設(shè)計的核心概念。但更關(guān)鍵的是，它能使開發(fā)人員的生活更輕松。

數(shù)據(jù)庫規(guī)范化的主要思想是減少數(shù)據(jù)冗余并確保數(shù)據(jù)存儲整潔、有邏輯。數(shù)據(jù)庫規(guī)范化的級別取決于數(shù)據(jù)庫的“規(guī)范形式”。迄今有最多六種規(guī)范形式(有爭議)，但實際需要了解的只是前三種。簡單來說，以下是主要規(guī)則：

第一范式(1NF)指出單個字段應(yīng)存儲單個數(shù)據(jù)點，并且所有行均應(yīng)唯一。不要在字段中存儲事物列表，這些屬于個人記錄。

第二范式(2NF)指出每個表應(yīng)具有單個主鍵列。創(chuàng)建唯一的ID。不必使用名稱和地址作為復(fù)合鍵，只需給用戶提供唯一的ID號或GUID。

第三范式(3NF)指出不允許功能傳遞依賴項。這條可能是最復(fù)雜的一項，從本質(zhì)上意味著如果有一個依賴于另一個字段的字段，則應(yīng)將該字段分解到另一個表中。這允許外鍵更改-不能更改實際值。

這里的重點是數(shù)據(jù)應(yīng)該是最小單位，因此具有重復(fù)數(shù)據(jù)的大表將拆分為具有易于搜索的鍵的較小表，從而使過濾更有效、查詢更直接，你的工作也會更加輕松!

數(shù)據(jù)庫對象

圖源：unsplash

如果你身兼數(shù)職，或者公司沒有數(shù)據(jù)庫團隊，那么你可能會負責(zé)數(shù)據(jù)庫開發(fā)。這種情況下，你應(yīng)該不同情況下使用哪種類型的數(shù)據(jù)庫對象有很好的了解。簡言之，數(shù)據(jù)庫對象是可以使用創(chuàng)建腳本存儲或訪問數(shù)據(jù)的任何內(nèi)容，最常見的例子就是表格，它是數(shù)據(jù)庫的組成部分。這些顯然是數(shù)據(jù)存儲的必經(jīng)之路。

但是，還有其他類型的對象以不同的方式訪問和轉(zhuǎn)換數(shù)據(jù)。使用最好的對象進行工作很重要。下面是使用案例中應(yīng)用對象的基本規(guī)則(索引本質(zhì)上是數(shù)據(jù)庫對象，因為它們會影響數(shù)據(jù)的存儲和訪問方式)：

存儲過程：這是處理或轉(zhuǎn)換數(shù)據(jù)的必經(jīng)之路。如果需要在一天中的特定時間或以特定的節(jié)奏進行更新，則可以創(chuàng)建存儲過程，然后按程序運行。 ·

視圖：視圖本質(zhì)上是一個存儲的查詢，可以從動態(tài)數(shù)據(jù)集中進行選擇。如果數(shù)據(jù)需要刷新或可能轉(zhuǎn)換，筆者常用視圖替換緩存的表。實際上并沒有存儲任何更改，但可以加入計算所得的字段，當你需要動態(tài)的最新數(shù)據(jù)時，視圖就是一個不錯的選擇。

了解了表、視圖和存儲過程之后，你將能夠處理大多數(shù)數(shù)據(jù)庫開發(fā)任務(wù)。

[[373440]]

圖源：unsplash

索引

首先需要了解的索引概念是聚集索引和非聚集索引之間的區(qū)別。

聚集索引：根據(jù)索引將所有數(shù)據(jù)存儲在表中。只能有一個聚集索引，默認情況下，主鍵為聚集。

非聚集索引：將索引字段與表分開存儲。該索引字段指向表中存儲的數(shù)據(jù)，就像書的索引一樣。

要提高查詢效率，就要增加存儲量。非聚集索引需要自己存儲，因為它們與表數(shù)據(jù)保持獨立。僅索引需要過濾或加入的字段，以便在存儲和性能之間找到最佳平衡。

索引編制是優(yōu)化數(shù)據(jù)庫性能的最佳方法。索引會影響數(shù)據(jù)在頁面中的存儲方式。默認情況下，記錄不會以特定的順序存儲，因此本質(zhì)上對字段建立索引就能使數(shù)據(jù)以可預(yù)測的方式存儲。在該字段上進行篩選時，查詢將運行得更快，因為SQL Server知道從那個確切的位置開始查找。

可以為特定目的在字段上設(shè)置許多索引，但是如果要提高性能，我們通常會創(chuàng)建通用的非聚集索引。此外，如果要創(chuàng)建索引，就必須進行維護，插入、更新和刪除會造成索引碎片。

因此，除非數(shù)據(jù)沒有更新，否則就需要根據(jù)數(shù)據(jù)更改的頻率來重建索引。理想情況下應(yīng)該使用計劃的存儲過程來執(zhí)行此操作，以便始終保持運行穩(wěn)定。

創(chuàng)建索引的SQL語句非常簡單。下面的語句將在Orders表的給定字段上創(chuàng)建一個名為 idx_orderdate的非聚集索引：

CREATE INDEX idx_orderdate ON Orders (OrderDate); 

讀取查詢計劃

如果想更深入地了解數(shù)據(jù)庫性能，讀取查詢計劃非常有用。運行查詢時，SQL Server會根據(jù)執(zhí)行計劃對其進行處理。你可以在運行查詢時生成計劃，或者如果查詢已在運行，則查看緩存的計劃，可以查看在查詢的每個步驟上花費了多長時間。

有經(jīng)驗的SQL向?qū)Э梢詮牟樵冇媱澲凶x取很多細微差別。但是，專業(yè)的開發(fā)人員需要知道的是搜索和掃描之間的區(qū)別。

• 掃描：可以是索引掃描或表掃描，但是無論哪種方式，SQL Server都必須掃描整個表或索引以查找數(shù)據(jù)。
• 搜索：對于索引搜索，SQL Server能夠基于給定的索引來識別要查詢的數(shù)據(jù)。

搜尋通常更有效。如果要優(yōu)化查詢，則應(yīng)確定查詢中掃描的位置并進行修復(fù)。解決它們的最簡單方法是確保加入了索引字段。

如果缺少查詢中可能使用的索引，SQL Server會發(fā)出通知。該建議將出現(xiàn)在查詢計劃的頂部。如果右鍵單擊建議索引的查詢計劃，然后選擇“缺少索引詳細信息”，甚至可以生成索引創(chuàng)建腳本。

[[373441]]

圖源：unsplash

恭喜，你已經(jīng)提高了SQL技能!現(xiàn)在可以使用這些概念優(yōu)化數(shù)據(jù)庫并更有效地進行查詢。無論是從應(yīng)用程序中查詢還是構(gòu)建自己的存儲過程和視圖，這些技巧都會使工作更加輕松!