聚集索引，數(shù)據(jù)實(shí)際上是按順序存儲(chǔ)的，數(shù)據(jù)頁(yè)就在索引頁(yè)上。就好像參考手冊(cè)將所有主題按順序編排一樣。一旦找到了所要搜索的數(shù)據(jù)，就完成了這次搜索，對(duì)于非聚集索引，索引是安全獨(dú)立于數(shù)據(jù)本身結(jié)構(gòu)的，在索引中找到了尋找的數(shù)據(jù)，然后通過(guò)指針定位到實(shí)際的數(shù)據(jù)。

SQL Server中的索引使用標(biāo)準(zhǔn)的B-樹(shù)來(lái)存儲(chǔ)他們的信息，如下圖所示，B-樹(shù)通過(guò)查找索引中的一個(gè)關(guān)鍵之來(lái)提供對(duì)于數(shù)據(jù)的快速訪問(wèn)，B-樹(shù)以相似的鍵記錄聚合在一起，B不代表二叉(binary),而是代表balanced（平衡的），而B(niǎo)-樹(shù)的一個(gè)核心作用就是保持樹(shù)的平衡。同伙向下遍歷這棵樹(shù)以找到一個(gè)數(shù)值并定位記錄。因?yàn)闃?shù)是平衡的，所以尋找任何記錄都只需要等量的資源，而且獲取的速度總是一致的—因?yàn)閺母饕~索引都具有相同的深度。



索引的中間層次是根據(jù)表的行數(shù)一級(jí)索引行的大小而變化的，如果使用一個(gè)較長(zhǎng)的鍵（KEY）來(lái)創(chuàng)建索引，一個(gè)分頁(yè)上就只容納較少的條目，因而索引就需要更多分頁(yè)（或者說(shuō)更多層），頁(yè)越多那么查找就需要話費(fèi)相對(duì)較長(zhǎng)的時(shí)間來(lái)找到所需要的信息，索引就可能不太有用了。

聚集索引

聚集索引的葉級(jí)別不僅包含了索引鍵，還包含了數(shù)據(jù)頁(yè)。另一種說(shuō)法數(shù)據(jù)本身也是聚集索引的一部分，聚集索引基于鍵值保持表中的數(shù)據(jù)有序，表中的數(shù)據(jù)頁(yè)是通過(guò)一個(gè)被稱作頁(yè)鏈（page chain）的雙向鏈接表來(lái)維護(hù)的，由于實(shí)際的數(shù)據(jù)頁(yè)的頁(yè)鏈只能按一種方式排序，因此一張表只能擁有一個(gè)聚集索引。
這里可能有一個(gè)誤區(qū)，有很多介紹SQL Server索引的文檔會(huì)告訴讀者：聚集索引按照排序順序（sorted order）物理地存儲(chǔ)數(shù)據(jù)。如果以為物理存儲(chǔ)就是磁盤本身的話就會(huì)產(chǎn)生誤解。試想如果聚集索引需要按照特定順序在實(shí)際的磁盤上維護(hù)數(shù)據(jù)的話，那么任何修改操作都將會(huì)產(chǎn)生相當(dāng)高昂的代價(jià)。當(dāng)一個(gè)頁(yè)變滿了需要一分為二的時(shí)候，所有后續(xù)頁(yè)面上的數(shù)據(jù)都必須向后移動(dòng)。聚集索引中的排序順序（sorted order）僅僅表示數(shù)據(jù)頁(yè)鏈在邏輯上是有序的。
大多數(shù)表都應(yīng)該需要一個(gè)聚集索引。優(yōu)化器非常傾向于采用聚集索引，因?yàn)榫奂饕軌蛑苯釉谌~級(jí)別找到數(shù)據(jù)。由于定義了數(shù)據(jù)的邏輯順序，聚集索引能夠特別快的訪問(wèn)針對(duì)范圍值的查詢，查詢優(yōu)化器能夠發(fā)現(xiàn)只有某一段范圍的數(shù)據(jù)頁(yè)需要掃描。

非聚集索引

對(duì)于非聚集索引，葉級(jí)別不包含全部的數(shù)據(jù)。除了鍵值之外，每個(gè)葉級(jí)別（樹(shù)的最底層）中的索引行包含了一個(gè)書簽（bookmark），告訴SQL Server可以在那里找到與索引鍵相應(yīng)的數(shù)據(jù)行。一個(gè)書簽可能有兩種形式。如果表上存在聚集索引，書簽就是相應(yīng)的數(shù)據(jù)行的聚集索引鍵。如果彪是堆（heap）結(jié)構(gòu)，書簽就是一個(gè)行表示（row identifier，RID），以“文件號(hào)：頁(yè)號(hào)：槽號(hào)”的格式來(lái)定位實(shí)際的行。
主鍵（PRIMARY KEY）與聚集索引（CLUSTER INDEX）
嚴(yán)格來(lái)說(shuō)，主鍵與聚集索引沒(méi)有任何關(guān)系，如果要說(shuō)有話，那就是表中沒(méi)有聚集索引的時(shí)候，創(chuàng)建的主鍵默認(rèn)就是聚集索引（除非有特別設(shè)置為NOCLUSTER）。
在主鍵與聚集索引的處理方面，注意以下事項(xiàng)：
1、主鍵不與聚集索引分離
2、聚集索引鍵列盡量避免使用int之外的數(shù)據(jù)類型
3、盡量避免使用復(fù)合主鍵

創(chuàng)建索引時(shí)的注意事項(xiàng)

1、始終包含聚集索引
當(dāng)表中不包含聚集索引時(shí)，表中的數(shù)據(jù)是無(wú)序的，這會(huì)降低數(shù)據(jù)檢索效率。即使通過(guò)索引縮小了數(shù)據(jù)檢索的范圍，但由于數(shù)據(jù)本身是無(wú)序的，當(dāng)從表中提取實(shí)際數(shù)據(jù)時(shí)，會(huì)產(chǎn)生頻繁的定位問(wèn)題，這也使得SQL Server基本上不會(huì)使用無(wú)聚集索引表中的索引來(lái)檢索數(shù)據(jù)。
2、保證聚集索引唯一
由于聚集索引是非聚集索引的行定位器，如果它不唯一，則會(huì)使行定位器中包含輔助數(shù)據(jù)，同時(shí)也導(dǎo)致從表中提取數(shù)據(jù)時(shí)，需要借助行定位器中的輔助數(shù)據(jù)來(lái)定位，這會(huì)降低處理效率。
3、保證聚集索引最小
每個(gè)聚集鍵值都是所有非聚集索引的葉結(jié)點(diǎn)記錄，它越小，意味著每個(gè)非聚集索引的索引葉包含的有效數(shù)據(jù)越多，這對(duì)于提升索引效率很有好處。
4、覆蓋索引
覆蓋索引是指索引中的列包含了數(shù)據(jù)處理中涉及的所有列，覆蓋索引相當(dāng)原始表的一個(gè)子集，由于這個(gè)子集中包含了數(shù)據(jù)處理涉及的所有列，因此操作這個(gè)子集就可以滿足數(shù)據(jù)處理需要。一般而言，如果大多數(shù)處理都只涉及某個(gè)大表的某些列，可以考慮為這些列建立覆蓋索引。
覆蓋索引的建立方法是將要包含的列中的關(guān)鍵列做為索引鍵列，將其他列做為索引的包含列（使用索引創(chuàng)建語(yǔ)句中的INCLUDE子句）。
5、適量的索引
當(dāng)數(shù)據(jù)發(fā)生變化時(shí)，SQL Server會(huì)同步維護(hù)相關(guān)索引中的數(shù)據(jù)，過(guò)多的索引會(huì)加影響數(shù)據(jù)變更的處理效率。因此，只應(yīng)該在經(jīng)常使用的列上建立索引。
適量的索引還體現(xiàn)在對(duì)索引列的組合方式的控制上。例如，如果有兩個(gè)列col1和col2，這兩個(gè)列的組合會(huì)產(chǎn)生三種使用情況：?jiǎn)为?dú)使用col1、單獨(dú)使用col2及同時(shí)使用col1和col2。如果有為每種情況都建立索引，則需要建立三個(gè)索引。但也可以只建立一個(gè)復(fù)合索引（col1, col2），這樣能夠依次滿足col1+col2、col1、col2這三種方式的查詢，其中，col2利用這個(gè)查詢會(huì)比較勉強(qiáng)（還要配合單獨(dú)的統(tǒng)計(jì)），可以視實(shí)際情況確定是否需要為col2建立單獨(dú)的索引。
特別注意：
不要建立重復(fù)索引，目前最常見(jiàn)的重復(fù)索引是單獨(dú)為某個(gè)列建立主鍵和聚集索引
與直接從表中提取數(shù)據(jù)相比，根據(jù)索引檢索數(shù)據(jù)，多了一個(gè)索引檢索的過(guò)程，這個(gè)過(guò)程要求能夠盡量縮小數(shù)據(jù)檢索范圍，并且使用最少的時(shí)間，這樣才能真正保證能夠通過(guò)索引提高數(shù)據(jù)檢索效率。
實(shí)現(xiàn)上述目的，對(duì)于索引鍵列的選擇，應(yīng)該遵循如下原則：
選擇性原則
選擇性是滿足條件的記錄占總記錄數(shù)的百分比，這個(gè)比率應(yīng)該盡可能低，這樣才能保證通過(guò)索引掃描后，只需要從基礎(chǔ)表提取很少的數(shù)據(jù)。
如果這個(gè)比率偏高，則不應(yīng)該考慮在此列上建立索引。
數(shù)據(jù)密度原則
數(shù)據(jù)密度是指列值唯一的記錄占總記錄數(shù)的百分比，這個(gè)比率越高，則說(shuō)明此列越適合建立索引。
在考慮數(shù)據(jù)密度的時(shí)候，還要注意數(shù)據(jù)分布的問(wèn)題，只有經(jīng)常檢索的密度高時(shí)，才適合建立索引。例如，如果一張表有10萬(wàn)記錄，雖然某個(gè)列不重復(fù)的記錄有9萬(wàn)條，但如果經(jīng)常檢索的2萬(wàn)條記錄，其不重復(fù)的列值才幾十條的話，這個(gè)列是不太適合建立索引的。另一種情況是，整體數(shù)據(jù)密度不大，但經(jīng)常檢索的數(shù)據(jù)的密度大，例如訂單的狀態(tài)，一般來(lái)說(shuō)，訂單的狀態(tài)就幾種，但已經(jīng)Close的訂單往往占整個(gè)數(shù)據(jù)的絕大部分，但數(shù)據(jù)處理的時(shí)候，基本上都是檢索未Close的訂單，這種情況下，為訂單的狀態(tài)列建立索引還是比較有效的（SQL Server 2008中，可以為這種列建立具有更佳效果的篩選索引）。
6、索引鍵列大小
一般不宜為超過(guò)100Byte的列建立索引。
7、復(fù)合索引鍵列順序
在索引中，索引的順序主要由索引中的每一個(gè)鍵列確定，因此，對(duì)于復(fù)合索引，索引中的列順序是很重要的，應(yīng)該優(yōu)先把數(shù)據(jù)密度大，選擇性列，存儲(chǔ)空間小的列放在索引鍵列的前面。