本篇內容主要講解“SQL Server索引設計基礎知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“SQL Server索引設計基礎知識點有哪些”吧!
就像一本書，書本末尾有一個索引，可幫助快速查找書籍內的信息。 索引是按順序排列的關鍵字列表，每個關鍵字旁邊是一組頁碼，這些頁碼指向可在其中找到每個關鍵字的頁面。
行存儲索引也一樣：它是按順序排列的值列表，每個值都有指向這些值所在的數據頁面的指針。 索引本身存儲在頁上，稱為索引頁。
索引是與表或視圖關聯的磁盤上或內存中結構，可以加快從表或視圖中檢索行的速度。 行存儲索引包含由表或視圖中的一列或多列生成的鍵。 對于行存儲索引，這些鍵以樹結構（B+ 樹）存儲，使數據庫引擎可以快速高效地找到與鍵值關聯的一行或多行。
行存儲索引將邏輯組織的數據存儲為包含行和列的表，物理上以行數據格式（稱為 行存儲1）存儲，或以名為列 存儲的列數據格式存儲。
為數據庫及其工作負荷選擇正確的索引是一項需要在查詢速度與更新所需開銷之間取得平衡的復雜任務。 如果基于磁盤的行存儲索引較窄，或者說索引關鍵字中只有很少的幾列，則需要的磁盤空間和維護開銷都較少。 而另一方面，寬索引可覆蓋更多的查詢。 您可能需要試驗若干不同的設計，才能找到最有效的索引。 可以添加、修改和刪除索引而不影響數據庫架構或應用程序設計。 因此，應試驗多個不同的索引而無需猶豫。
數據庫引擎的查詢優化器可在大多數情況下可靠地選擇最高效的索引。 總體索引設計策略應為查詢優化器提供可供選擇的多個索引，并依賴查詢優化器做出正確的決定。 這在多種情況下可減少分析時間并獲得良好的性能。
不要總是將索引的使用等同于良好的性能，或者將良好的性能等同于索引的高效使用。 如果只要使用索引就能獲得最佳性能，那查詢優化器的工作就簡單了。 但事實上，不正確的索引選擇并不能獲得最佳性能。 因此，查詢優化器的任務是只在索引或索引組合能提高性能時才選擇它，而在索引檢索有礙性能時則避免使用它。
行存儲是存儲關系表數據的傳統方法。 “行存儲”是指基礎數據存儲格式為堆、B+ 樹（聚集索引）或內存優化表的表。 “基于磁盤的行存儲”排除了內存優化表。
了解數據庫本身的特征。例如，內存優化表和索引提供無閂鎖設計，尤其適用于數據庫是否是頻繁修改數據的聯機事務處理 (OLTP) 數據庫的應用場景。 或者， 列存儲索引尤其適用于典型的數據倉庫數據集。 列存儲索引可以通過為常見數據倉庫查詢（如篩選、聚合、分組和星型聯接查詢）提供更快的性能，以轉變用戶的數據倉庫體驗。
了解最常用的查詢的特征。 例如，了解到最常用的查詢聯接兩個或多個表將有助于決定要使用的最佳索引類型。
了解查詢中使用的列的特征。 例如，某個索引對于含有整數數據類型同時還是唯一的或非空的列是理想索引。
確定哪些索引選項可在創建或維護索引時提高性能。 例如，對某個現有大型表創建聚集索引將會受益于 ONLINE 索引選項。 ONLINE 選項允許在創建索引或重新生成索引時繼續對基礎數據執行并發活動。
確定索引的最佳存儲位置。非聚集索引可以與基礎表存儲在同一個文件組中，也可以存儲在不同的文件組中。 索引的存儲位置可通過提高磁盤 I/O 性能來提高查詢性能。
使用動態管理視圖 (DMV)（例如 sys.dm_db_missing_index_details 和 sys.dm_db_missing_index_columns）識別缺失索引時，可能會在同一個表和列上獲得類似的索引變體。 檢查表上的現有索引以及缺失索引建議，以防止創建重復索引。
了解數據庫、查詢和數據列的特征可以幫助設計出最佳索引。
設計索引時，應考慮以下數據庫準則：
對表編制大量索引會影響 INSERT、UPDATE、DELETE 和 MERGE 語句的性能，因為當表中的數據更改時，所有索引都須適當調整。避免對經常更新的表進行過多的索引，并且索引應保持較窄，就是說，列要盡可能少；使用多個索引可以提高更新少而數據量大的查詢的性能。 大量索引可以提高不修改數據的查詢（例如 SELECT 語句）的性能，因為查詢優化器有更多的索引可供選擇，從而可以確定最快的訪問方法。
對小表進行索引可能不會產生優化效果，因為查詢優化器在遍歷用于搜索數據的索引時，花費的時間可能比執行簡單的表掃描還長。 因此，小表的索引可能從來不用，但仍必須在表中的數據更改時進行維護。
視圖包含聚合、表聯接或聚合和聯接的組合時，視圖的索引可以顯著地提升性能。 若要使查詢優化器使用視圖，并不一定非要在查詢中顯式引用該視圖。
可以選擇啟用自動索引優化。
查詢存儲有助于識別性能不佳的查詢，并提供查詢執行計劃的歷史記錄，其中記錄由優化器選擇的索引。
設計索引時，應考慮以下查詢準則：
為經常用于查詢中的謂詞和聯接條件的列創建非聚集索引。 但是，應避免添加不必要的列。 添加太多索引列可能對磁盤空間和索引維護性能產生負面影響。
涵蓋索引可以提高查詢性能，因為符合查詢要求的全部數據都存在于索引本身中。 也就是說，只需要索引頁，而不需要表的數據頁或聚集索引來檢索所需數據，因此，減少了總體磁盤 I/O。
將插入或修改盡可能多的行的查詢寫入單個語句內，而不要使用多個查詢更新相同的行。 僅使用一個語句，就可以利用優化的索引維護。
評估查詢類型以及如何在查詢中使用列。 例如，在完全匹配查詢類型中使用的列就適合用于非聚集索引或聚集索引。
設計索引時，應考慮以下列準則：
對于聚集索引，請保持較短的索引鍵長度。 另外，對唯一列或非空列創建聚集索引可以使聚集索引獲益。
無法指定 ntext、 text、 image、 varchar(max) 、 nvarchar(max) 和 varbinary(max) 數據類型的列為索引鍵列。 不過， varchar(max) 、 nvarchar(max) 、 varbinary(max) 和 xml 數據類型的列可以作為非鍵索引列參與非聚集索引。
xml 數據類型的列只能在 XML 索引中用作鍵列。
檢查列的唯一性。 在同一個列組合的唯一索引而不是非唯一索引提供了有關使索引更有用的查詢優化器的附加信息。
在列中檢查數據分布。 通常情況下，為包含很少唯一值的列創建索引或在這樣的列上執行聯接將導致長時間運行的查詢。
考慮對具有定義完善的子集的列（例如，稀疏列、大部分值為 NULL 的列、含各類值的列以及含不同范圍的值的列）使用篩選索引。 設計良好的篩選索引可以提高查詢性能，降低索引維護成本和存儲成本。
如果索引包含多個列，則應考慮列的順序。 WHERE 子句中使用的列應位于等于 (=) 、大于 (>) 、小于 (<) 或 BETWEEN 搜索條件或參與聯接的列。 其他列應該基于其非重復級別進行排序，就是說，從最不重復的列到最重復的列。
考慮對計算列進行索引。
在確定某一索引適合某一查詢之后，可以選擇最適合具體情況的索引類型。 索引包含以下特性：
聚集還是非聚集
唯一還是非唯一
單列還是多列
索引中的列是升序排序還是降序排序
非聚集索引是全表還是經過篩選
列存儲與行存儲
內存優化表的哈希索引與非聚集索引
也可以通過SQL Server的設置選項自定義索引的初始存儲特征以優化其性能或維護。 而且，通過使用文件組或分區方案可以確定索引存儲位置來優化性能。
定義索引時，請考慮索引鍵列的數據是按升序還是按降序存儲。CREATE INDEX、CREATE TABLE 和 ALTER TABLE 語句的語法在索引和約束中的各列上支持關鍵字 ASC（升序）和 DESC（降序）：
當引用表的查詢包含用以指定索引中鍵列的不同方向的 ORDER BY 子句時，指定鍵值存儲在該索引中的順序很有用。 在這些情況下，索引就無需在查詢計劃中使用 SORT 運算符。因此，使得查詢更有效。
檢索數據以滿足此條件需要將 Purchasing.PurchaseOrderDetail 表中的 RejectedQty 列按降序（由大到?。┡判?，并且將 ProductID 列按升序（由小到大）排序，比如：
SELECT RejectedQty, ((RejectedQty/OrderQty)*100) AS RejectionRate, ProductID, DueDate FROM Purchasing.PurchaseOrderDetail ORDER BY RejectedQty DESC, ProductID ASC; GO
此查詢的下列執行計劃顯示了查詢優化器使用 SORT 運算符按 ORDER BY 子句指定的順序返回結果集。
如果使用與查詢的 ORDER BY 子句中的鍵列匹配的鍵列創建基于磁盤的行存儲索引，則無需在查詢計劃中使用 SORT 運算符，從而使查詢計劃更有效。
CREATE NONCLUSTERED INDEX IX_PurchaseOrderDetail_RejectedQty ON Purchasing.PurchaseOrderDetail (RejectedQty DESC, ProductID ASC, DueDate, OrderQty); GO
再次執行查詢后，下列執行計劃顯示未使用 SORT 運算符，而使用了新創建的非聚集索引。
到此，相信大家對“SQL Server索引設計基礎知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
