1.聚集索引和非聚集索引

2.索引的結構

3.索引包含列和書簽查找

前言

此文是我之前的筆記整理而來，以索引為入口進行探討相關數據庫知識（又做了修改以讓人更好消化）。SQL Server接觸不久的朋友可以只看以下藍色字體字，簡單有用節省時間；如果是數據庫基礎不錯的朋友，可以全看，歡迎探討。

索引的概念

索引的用途：我們對數據查詢及處理速度已成為衡量應用系統成敗的標準，而采用索引來加快數據處理速度通常是最普遍采用的優化方法。

索引是什么：數據庫中的索引類似于一本書的目錄，在一本書中使用目錄可以快速找到你想要的信息，而不需要讀完全書。在數據庫中，數據庫程序使用索引可以重啊到表中的數據，而不必掃描整個表。書中的目錄是一個字詞以及各字詞所在的頁碼列表，數據庫中的索引是表中的值以及各值存儲位置的列表。

索引的利弊：查詢執行的大部分開銷是I/O，使用索引提高性能的一個主要目標是避免全表掃描，因為全表掃描需要從磁盤上讀取表的每一個數據頁，如果有索引指向數據值，則查詢只需要讀少數次的磁盤就行啦。所以合理的使用索引能加速數據的查詢。但是索引并不總是提高系統的性能，帶索引的表需要在數據庫中占用更多的存儲空間，同樣用來增刪數據的命令運行時間以及維護索引所需的處理時間會更長。所以我們要合理使用索引，及時更新去除次優索引。

1.聚集索引和非聚集索引

索引分為聚集索引和非聚集索引

1.1 聚集索引

表的數據是存儲在數據頁中（數據頁的PageType標記為1），SqlServer一頁是8k，存滿一頁就開辟下一頁存儲。如果表有聚集索引，那么一筆一筆物理數據就是按聚集索引字段的大小升/降排序存儲在頁中。當對聚集索引字段更新或中間插入/刪除數據時，都會導致表數據移動（造成性能一定影響），因為它要保持升/降排序。

注意，主鍵只是默認是聚集索引，它也可以設置為非聚集索引，也可以在非主鍵字段上設置為聚集索引，全表只能有一個聚集索引。

一個優秀的聚集索引字段一般包含以下4個特性：

(A).自增長

總是在末尾增加記錄，減少分頁和索引碎片。

(B).不被更改

減少數據移動。

(C).唯一性

唯一性是任何索引最理想的特性，可以明確索引鍵值在排序中的位置。

更重要的是，索引鍵指唯一的話，它在每條記錄里才可以正確指向源數據行RID。如果聚集索引鍵值不唯一，SqlServer就需要內部生成uniquifier 列組合當作聚集鍵保證“鍵值”唯一性；如果非聚集索引鍵值不唯一，就會增加RID列（聚集索引鍵或者堆表中的行指針）保證“鍵值”唯一性。

思考（可略過）：索引“鍵值”在非葉子節點也有保證唯一性，原因應該是為了明確索引記錄在非葉子節點中的位置。比如有個非聚集索引字段Name2，表中有很多Name2=’a’的記錄，導致Name2=’a’在非葉子節點上有多條索引記錄（節點），這時候再insert一筆Name2=‘a’的記錄時，就可以根據非葉子節點的RID和新增記錄的RID很快確定要insert到哪個索引記錄（節點）上，如果沒有非葉子節點的RID，那得遍歷到所有Name2=’a’的葉子節點才能確定位置。另外，當我們select * from Table1 where Name2<=’a’時，返回的數據是按非聚集索引Name2和RID排序的，很好理解返回的數據就是按這邊索引存儲的順序排序的。這是這條sql查詢時有用到Name2索引的結果，如果數據庫查詢計劃因“臨界點”問題選擇直接表數據掃描，那返回的數據默認就是按表數據的順序排序的。

為了“鍵值”唯一性，對于聚集索引，uniquifier 列只在索引值重復時增加。對于非聚集索引，如果創建索引時沒定義唯一，RID會在所有記錄增加，就算索引值是唯一的；如果創建索引時定義唯一，RID只在葉子層增加，用于查找源數據行，即書簽查找操作。

(D).字段長度小

聚集索引鍵長度越小，一頁索引頁就可以容納更多索引記錄，進而減少索引B樹結構的深度。例如，一個百萬記錄的表有一個int聚集索引，可能只需要3層的B樹結構。如果把聚集索引定義在更寬的列（比如uniqueidentifier列需要16 字節），那么索引的深度會增加到4層。任何聚集索引查找需要4個I/O操作（確切的說是4個邏輯讀），原先只要3個I/O操作。
同樣，非聚集索引里會包含聚集索引鍵值，聚集索引鍵長度越小非聚集索引記錄也就越小，一頁索引頁就可以容納更多索引記錄。

1.2 非聚集索引

也是存儲在頁中（PageType標記為2的頁，叫索引頁)。比如表T建立了一個非聚集索引Index_A，那么表T有100條數據的話，那么索引Index_A也就有100條數據（準確的說是100條葉子節點數據，索引是B樹結構，如果樹的高度大于0，那么就有根節點頁或中間節點頁數據，這時索引數據就超過100條），如果表T還有非聚集索引Index_B，那么Index_B也是至少100條數據，所以索引建越多開銷越大。

更新索引字段、插入一條數據、刪除一條數據都會造成索引的維護從而造成性能的一定影響。在不同情況下，性能影響是不同的。比如當你有一個聚集索引，插入的數據又都是在末尾，這樣幾乎是不會造成數據移動，影響較小；如果插入的數據在中間位置，一般會導致數據移動，而且可能產生分頁和頁碎片，影響就會稍大一點（如果插入到的中間頁有足夠的剩余空間容納插入的數據，而且位置是在頁末，也是不會造成數據移動）

2.索引的結構

都說SqlServer的索引是B樹結構（這邊假定你對B樹結構有一定了解），那它到底長什么個模樣呢，可以用Sql語句來查看它的邏輯呈現。

新建查詢執行語法： DBCC IND(Test,OrderBo,-1) –其中Test庫的OrderBo表有1萬筆數據，有聚集索引Id主鍵字段
（不妨自己動手建個表，有聚集索引字段，插入1萬表數據，然后執行這個語法看看，會收獲很多，百聞不如一見）

執行結果：

如上圖，看到一個IndexLevel=2的索引頁2112（這邊它就是B樹的根節點，IndexLevel最大的就是根節點，往下就是子級、子子級…只有一個根頁作為B樹結構的訪問入口點），說明一定還有IndexLevel=1的索引頁和IndexLevel=0的葉子頁。由于這邊是聚集索引，因此當IndexLevel=0的葉子頁就是數據頁，存儲的是一筆一筆的物理數據。如上圖也可以看到，IndexLevel=0的行的PageType等于1，就是代表數據頁，上面1.1章節講到聚集索引時，也有提到PageType=1；而如果是非聚集索引，IndexLevel=0的葉子頁，PageType是等于 2，仍然是索引頁。

同樣，我們用Sql命令DBCC PAGE看一看

— DBCC TRACEON(3604,-1)
DBCC PAGE(Test,1,2112,3)
–根節點2112，可以查出它的兩個子節點2280和2448，然后對這兩個子節點再作DBCC PAGE查詢
DBCC PAGE(Test,1,2280,3)
DBCC PAGE(Test,1,2448,3)