集群索引:通往SQL Server索引級別3的階梯
David Durant,2013/01/25(第一次出版:2011/06/22)
該系列
本文是樓梯系列的一部分:SQL Server索引的階梯
索引是數據庫設計的基礎，并告訴開發人員使用數據庫非常了解設計器的意圖。不幸的是，當性能問題出現時，索引常常被添加到事后。這里最后是一個簡單的系列文章，它應該能讓任何數據庫專業人員快速“跟上”他們的步伐
這個階梯的前面的級別提供了一般的索引和非聚集索引的概述。它總結了關于SQL Server索引的關鍵概念。當請求到達數據庫時，無論是SELECT語句還是INSERT、UPDATE或DELETE語句，SQL Server只有三種可能的方法來訪問語句中引用的表的數據:
訪問非聚集索引，避免訪問表。只有在索引包含該查詢請求的該表的所有數據時才有可能
使用search key(s)訪問索引，然后使用選中的書簽(s)來訪問表的各個行。
忽略索引并搜索請求行的表。
這個層次的開始是關注上面列表中的第三個選擇;搜索表。這又將引導我們討論集群索引;在第2級中提到的，但未涉及的主題。
我們將在這個級別使用的主要AdventureWorks數據庫表是SalesOrderDetail表。在121317行中，它足夠大，足以說明在表上有聚集索引的一些好處。而且，有兩個外鍵，它非常復雜，足以說明您必須對集群索引做出的設計決策。
示例數據庫
雖然我們已經在第1級討論了示例數據庫，但它在這個時候重復。在整個樓梯中，我們將使用例子來闡明概念。這些示例基于Microsoft AdventureWorks示例數據庫。我們專注于銷售訂單。5個表將提供事務性和非事務性數據的良好組合;客戶，銷售人員，產品，銷售訂單，和銷售細節。為了保持注意力集中，我們使用了列的一個子集。因為AdventureWorks是一種標準化的，銷售人員信息被分解為三個表:銷售人員、員工和聯系人。
在整個樓梯中，我們使用以下兩個術語，指的是“行項目”和“訂單細節”。前者是更常見的商業術語;后者出現在AdventureWorks表的名稱中。
完整的表集以及它們之間的關系如圖1所示。

圖1:在這個樓梯的例子中使用的表
注:
在這個階梯級別顯示的所有TSQL代碼都可以連同文章一起下載。
聚集索引
我們首先提出以下問題:如果不使用非聚集索引，那么在表中找到一行(s)需要多少工作?是否為被請求的行搜索表，意味著掃描無序表中的每一行?或者，SQL Server可以永久地對表中的行進行排序，以便能夠快速地通過搜索鍵訪問它們，就像它通過搜索鍵快速訪問非聚集索引的條目一樣?答案取決于您是否指示SQL服務器在表上創建集群索引。
與非聚集索引不同，它們是單獨的對象，占用它們自己的空間，集群索引和表是相同的。通過創建集群索引，您可以指示SQL Server將表的行排序為索引鍵序列，并在以后的數據修改中維護該序列。即將到來的級別將查看生成的內部數據結構來完成此任務。但是現在，把聚集索引看作是可排序的表。給定一個行的索引鍵值，SQL Server可以快速訪問該行;然后可以按順序從這一行開始。
出于演示的目的，我們創建了示例表的兩個副本，SalesOrderDetail;一個沒有索引，一個有聚集索引。對于索引的鍵列，我們做出了與AdventureWorksdatabase的設計者相同的選擇:SalesOrderID / SalesOrderDetailID。清單1中的代碼制作了SalesOrderDetail表的副本。我們可以在任何時候重新運行這段代碼，我們希望以“干凈的slate”開始。

IF EXISTS (SELECT * FROM sys.tables  WHERE OBJECT_ID = OBJECT_ID('dbo.SalesOrderDetail_index')) DROP TABLE dbo.SalesOrderDetail_index; GO IF EXISTS (SELECT * FROM sys.tables  WHERE OBJECT_ID = OBJECT_ID('dbo.SalesOrderDetail_noindex')) DROP TABLE dbo.SalesOrderDetail_noindex; GO SELECT * INTO dbo.SalesOrderDetail_index FROM Sales.SalesOrderDetail; SELECT * INTO dbo.SalesOrderDetail_noindex FROM Sales.SalesOrderDetail; GO CREATE CLUSTERED INDEX IX_SalesOrderDetail ON dbo.SalesOrderDetail_index (SalesOrderID, SalesOrderDetailID) GO

?

清單1:創建SalesOrderDetail表的副本
因此，假設SalesOrderDetail表在創建集群索引之前是這樣的:

SalesOrderID SalesOrderDetailID ProductID?? OrderQty UnitPrice
69389??????? 102201???????????? 864???????? 3??????? 38.10
56658??????? 59519????????????? 711???????? 1??????? 34.99
59044??????? 70000????????????? 956 ????????2??????? 1430.442
48299??????? 22652????????????? 853???????? 4??????? 44.994
50218??????? 31427????????????? 854???????? 8??????? 44.994
53713??????? 50716????????????? 711???????? 1??????? 34.99
50299??????? 32777????????????? 739???????? 1????? ??744.2727
45321??????? 6303?????????????? 775???????? 6??????? 2024.994
72644??????? 115325???????????? 873???????? 1??????? 2.29
48306??????? 22705????????????? 824???????? 4??????? 141.615
69134??????? 101554???????????? 876???????? 1??????? 120.00
48361??????? 23556????????????? 760???????? 3??????? 469.794
53605??????? 50098????????????? 888???????? 1??????? 602.346
48317??????? 22901????????????? 722???????? 1??????? 183.9382
66430??????? 93291????????????? 872???????? 1??????? 8.99
65281??????? 90265????????????? 889???????? 2??????? 602.346
52248??????? 43812????????????? 871???????? 1??????? 9.99
47978??????? 20189????????????? 794???????? 2??????? 1308.9375

After creating the clustered index shown above, the resulting table / clustered index would look like this:

SalesOrderID SalesOrderDetailID ProductID?? OrderQty UnitPrice
43668??????? 106??????????????? 722???????? 3????????? 178.58
43668??????? 107??????????????? 708???????? 1?????????? 20.19
43668??????? 108??????????????? 733???????? 3? ????????356.90
43668??????? 109??????????????? 763???????? 3????????? 419.46
43669??????? 110??????????????? 747???????? 1????????? 714.70
43670??????? 111??????????????? 710???????? 1??????????? 5.70
43670??????? 112??????????????? 709???????? 2????????? ??5.70
43670??????? 113??????????????? 773???????? 2??????? 2,039.99
43670??????? 114??????????????? 776???????? 1??????? 2,024.99
43671??????? 115??????????????? 753???????? 1??????? 2,146.96
43671??????? 116??????????????? 714???????? 2?????????? 28.84
43671??????? 117??????????????? 756???????? 1????????? 874.79
43671??????? 118??????????????? 768???????? 2????????? 419.46
43671??????? 119??????????????? 732???????? 2????????? 356.90
43671??????? 120??????????????? 763???????? 2????????? 419.46
43671?? ?????121??????????????? 755???????? 2????????? 874.79
43671??????? 122??????????????? 764???????? 2????????? 419.46
43671??????? 123??????????????? 716???????? 1?????????? 28.84
43671??????? 124??????????????? 711???????? 1?????????? 20.19
43671??????? 125??????????????? 708???????? 1?????????? 20.19
43672??????? 126??????????????? 709???????? 6??????????? 5.70
43672??????? 127??????????????? 776???????? 2??????? 2,024.99
43672??????? 128??????????????? 774???????? 1??????? 2,039.99
43673??????? 129??????? ????????754???????? 1????????? 874.79
43673??????? 130??????????????? 715???????? 3?????????? 28.84
43673??????? 131??????????????? 729???????? 1????????? 183.94

當您查看上面顯示的示例數據時，您可能會注意到每個SalesOrderDetailID值都是惟一的。不要混淆;SalesOrderDetailID并不是表的主鍵。SalesOrderID / SalesOrderDetailID的組合是表的主鍵;以及聚集索引的索引鍵。
了解集群索引的基礎知識
集群索引鍵可以由您選擇的任何列組成;它不必基于主鍵。在我們的示例中，最重要的是，鍵的左大部分列是外鍵，SalesOrderID值。因此，銷售訂單的所有行項都在SalesOrderDetail表中連續出現。
請記住這些關于SQL Server集群索引的附加點:
由于聚集索引的條目是表的行，在集群索引條目中沒有書簽值。當SQL Server已經在一行時，它不需要一個信息來告訴它在哪里找到這一行。
集群索引總是覆蓋查詢。由于索引和表是相同的，所以表的每一列都在索引中。
在表上有集群索引不會影響您在該表上創建非聚集索引的選項。
選擇聚集索引鍵列(s)
每個表最多只能有一個集群索引。表的行只能在一個序列中。你需要決定哪個序列，如果有的話，對每個表都是最好的;并且，如果可能的話，在表填充數據之前創建聚集索引。在做這個決定的時候，要記住，排序不僅意味著排序，還意味著分組;按銷售順序分組。
這就是為什么AdventureWorksdatabase的設計者在SalesOrderID中選擇SalesOrderDetailID作為SalesOrderDetail表的序列;這是線條項目的自然順序。
例如，如果用戶請求一個訂單的行項，他們通常會請求該訂單的所有行項。一個典型的銷售訂單表格告訴我們，訂單的打印副本總是包含所有的行項目。按銷售訂單的順序排列，是銷售訂單業務的性質。倉庫可能偶爾會有請求，希望通過產品而不是銷售訂單來查看產品;但是大部分的請求;例如銷售人員、客戶或打印發票的程序，或計算每個訂單總價值的查詢;對于任何給定的銷售訂單，將需要所有的行項目。
然而，僅用戶需求并不能確定什么是最好的集群索引。本系列的未來水平將涵蓋索引的內部;因為索引的某些內部方面也會影響到集群索引列的選擇。
堆
如果表中沒有聚集索引，那么表稱為堆。每個表要么是堆，要么是聚集索引。因此，盡管我們經常聲明每個索引屬于兩種類型之一，集群或非集群;同樣重要的是要注意，每個表都屬于兩種類型之一;它是一個聚集索引，或者是堆。開發人員經常說，表“有”或“沒有”聚集索引，但更有意義的是，表“是”或“不是”聚集索引。
在尋找行(不包括使用非聚集索引)時，SQL Server只有一種方法可以搜索堆(不包括使用非聚集索引)，這將從表的第一行開始，然后遍歷表，直到所有的行都被讀取。沒有序列，就沒有搜索鍵，也無法快速導航到特定的行。
將聚集索引與堆進行比較
為了評估集群索引與堆的性能，清單1列出了兩份SalesOrderDetailtable的副本。一個副本是堆版本，另一個副本是在原始表上創建相同的集群索引(SalesOrderID、SalesOrderDetailID)。兩個表都沒有任何非聚集索引。
我們將對表的每個版本運行相同的三個查詢;一個檢索單個行，一個為單個訂單檢索所有行，一個為單個產品檢索所有行。我們將在下面顯示的表中顯示SQL和每個執行的結果。
我們的第一個查詢檢索單個行，執行細節如表1所示。

表1:檢索一行
我們的第二個查詢為單個銷售訂單檢索所有行，您可以看到表2中的執行細節。

sql ? ? select *
從SalesOrderDetail
在SalesOrderID = 43671
堆(s)(11行受影響)
表“SalesOrderDetail_noindex”。掃描計數1，邏輯讀1495。
群集索引(11行(s)受影響)
表“SalesOrderDetail_noindex”。掃描計數1，邏輯讀3。
將群集索引io的影響從1495讀到3讀。
與前面的查詢相同的統計信息。堆仍然需要一個表掃描，而群集索引將請求的訂單的11個細節行組合在一起，以便能夠檢索11行，就像檢索一行的IO所需要的一樣。一個即將到來的級別將詳細解釋為什么不需要額外的讀取來檢索額外的10行。

表2:為單個SalesOrder檢索所有行
第三個查詢檢索單個產品的所有行，執行結果如表3所示。
SQL
SELECT *
從SalesOrderDetail
在ProductID = 755
堆
(228行受影響)
表“SalesOrderDetail_noindex”。掃描計數1，邏輯讀1495。
群集索引(228行(s)受影響)
表“SalesOrderDetail_index”。掃描計數1，邏輯讀取1513。
對聚集索引版本的集群索引io的影響稍微大一些;1513閱讀與1495讀。
在ProductID列上沒有非聚集索引的注釋幫助查找單個產品的行，這兩個版本都需要掃描。由于有集群索引的開銷，集群索引版本是稍微大一點的表;因此，掃描它需要更多的讀取，而不是掃描堆。

表3:檢索單個產品的所有行
我們的前兩個查詢大大受益于聚集索引的存在;第三個是近似相等的。是否有時聚類索引是一種損害?答案是肯定的，它主要與插入、更新和刪除行有關。就像在這些早期的層次中遇到的許多其他的索引一樣，它也是一個將在更高層次上更詳細地討論的主題。
一般來說，檢索收益大于維護損失;使聚集索引更適合堆。如果您在Azure數據庫中創建表，則沒有選擇;每個表都必須是一個聚集索引。
結論
集群索引是一個排序表，它的序列由您在創建索引時指定，并由SQL Server維護。該表中的任何一行都可以通過其鍵值快速訪問。在索引鍵序列中，任何一組行，都可以快速訪問，因為它們的鍵的范圍很廣。
每個表只能有一個集群索引。哪個列應該是聚集索引鍵列的決定是您將為任何表做出的最重要的索引決定。
在第4級，我們將重點從邏輯轉移到物理上，引入頁面和區段，并檢查索引的物理結構。

?

?

轉載于:https://www.cnblogs.com/yyyz516/p/7942324.html

總結

以上是生活随笔為你收集整理的翻译：集群索引:通往SQL Server索引级别3的阶梯的全部內容，希望文章能夠幫你解決所遇到的問題。

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