索引結構被分為兩類索引組件：葉級(leaf level)和非葉級(non-leaf Level(s)) 。

一個聚集索引的葉級包含索引鍵和數據。“聚集索引的葉級除了鍵值還有什么？”答案是“其他的任何東東(everything else)”。也就是說，表中的所有行的列都在一個聚集索引的葉級中。換種說法是：當一個聚集索引被創建的時候，數據(data)變成了聚集索引的葉級， 同 時，表中的數據被聚集鍵復制和排序。一旦被創建，一個聚集索引被邏輯維護而不是物理維護，排序被通過一個雙鏈列表（稱為頁鏈page Chain)維護。（注意：在一個堆(Heap)中頁是不會有任何方式互相鏈接的。 ）在頁鏈中的頁的排序和數據頁中行的排序，均是基于聚集 索引的定義。決定哪些列用于索引是一個重要的性能參考指標。

由于數據頁的實際頁鏈只能被一種方式排序，所以一個表只能有一個聚集索引。而且，通常情況下，大多數在使用聚集索引的時候性能更佳。然而，聚集鍵需 要被慎重選擇，為了適當選擇索引鍵，你必須理解索引是如何工作的。即聚集鍵的內部依賴，特別是非聚集索引。

位于聚集鍵上的非聚集索引的依賴(dependency)在SQL Server 7.0時代存儲引擎被重新架構時就已經存在了，它最初是用于（當使用一個非聚集索引去引用表中相應的行時）行如何被標識。如果一個表有聚集索引，行被聚集 鍵標記(和查找）。如果沒有聚集索引，則行被物理行標識(identifier RID)標記（和查找）。查找相應的數據行的處理就好像查找書的書簽。

非聚集索引僅僅包含索引定義的數據 。當在一個非聚集索引中查找一行的時候，你通常不得不到實際的數據行以得到沒有包含在非聚集索引部 分的數據。為了檢索這部分附加數據，你必須深入表的內部。

首先 ，最重要的是，所有聚集索引必須是惟一的。為什么必須是惟一的首要原因是非聚集索引項能夠準確地指向一個特定的行?？紤]到如果一 個表被最后一個名字（last name)的不惟一的值聚集，問題來了。如果一個非聚集索引存在于一個惟一的值，比如社會安全號（對我們而言就是身份證號），一個查詢社會安全號為 123-45-6789的索引，結果，聚集鍵是“Smith”,那么多個最后名字為Smith的行出現，到底是哪個？這個社會安全號為 123-45-6789的特定行，如何被有效定位？

為了聚集鍵能被有效使用，所有非聚集索引項必須準確地指向一行。因為SQL Server中的指針是聚集索引，所以，聚集索引必須是惟一的。如果你創建一個聚集索引時沒有使用Unique關鍵字，系統在必要時會自動向這些行添加一 個惟一標志列以確保內部的惟一性。這個惟一標志(uniquifier)是一個4字節的整數，當行的聚集鍵不惟一時，自動被回到數據行，一旦被添加，它變 成了聚集鍵的一部分，意味著它在每一個非聚集索引中被復制?！?/p>

第二 ，如果一個聚集鍵(Clustering key)被用于從一個非聚集索引到一個聚集索引的（數據）內部查找相應的數據行，那么,這個聚集鍵是表中最被過多使用的數據。所有列都組織索引鍵，這些 鍵被包含于每一個非聚集索引附加于實際數據行中。結果，索引鍵的寬度變得重要了。考慮一個擁有12個非聚集索引和一百萬數據的表的一個聚集索引擁有64字 節的聚集健。不計算內部和結構頭部，僅僅用于存儲在每一個非聚集索引鍵的索引鍵將是732MB,而如果聚集鍵只有8字節的話，這開銷是92MB，而如果4 字節的話，將只有46MB。盡管這只是一個粗略的估計，它表明如果你使用了一個過寬的聚集鍵，將浪費大量的空間（以及潛在的緩 存池內存）,性能的損耗是比較可觀的。因此，一個過寬的非聚集索引是應該避免的。

第三，因為聚集索引鍵是整個表中最冗余的數據，你應該確信你的聚集鍵是不易變的(not volatile）,如果一個聚集健改變，它有以下幾個副作用：1、它會引起聚集索引內的記錄的搬遷，造成頁page的分離與碎片。2、它引起每一個非聚 集索引被修改，以便于所有相關的非聚集索引的行的索引鍵的值被糾正。這既浪費時間和空間，導致需要整理的碎片，增加了不必要的開銷（每個列重組聚集鍵）。

這三個屬性：惟一、窄和靜態也被用一個好的主鍵（但不總是）。因為你只有一個主鍵（僅僅一個聚集鍵）。SQL Server使用一個惟一的聚集索引以強化主鍵約束。然而，并不是每一個表的創建者（唉，別睡著了，說你呢！）都知道這一點。于是，主鍵沒有被堅持這些標 準(舉例，當主鍵被選為數據的自然健(natural key)，即，如一個寬的7個列的100個字節組合)，那么使用一個聚集索引去強化惟一性，并在每一個非聚集索引復制完全的100字節的列組合將具有極強 的反作用。l因此，對一些不知情的（unsuspecting）數據庫開發人員（具體就是剛才睡覺的那幾位),一個非常寬的聚集健在創建表時就被系統不知 不覺的加上了，好消息是：你可以定義主鍵是非聚集索引，并且輕易地在一個不同的列上創建一個聚集索引 。當然，你必須知道什么時候和怎樣做這 些。

最后，一個表的聚集鍵也應當以Insert時產生最小碎片為依據。盡管一旦聚集索引被創建后只有一個邏輯排序被維護，這個結構的維護確實有開銷。如 果行需要持續地被插入在隨機點（如插入一個以last name排序的表中），那么這個表的邏輯排序的維護成本比總是插入一個以自增長列排序的表（總是在表的末尾處）略微有些提高。

小結：表的聚集鍵應該基于表的用途，同時也應當基于SQL Server在聚集健的內部依賴。聚集鍵應該是惟一的、窄的、靜態的，最好，不斷增長？（ ever-increasing)。

好的聚集鍵的例子如下：

◆單個列鍵被定義為一個不斷增長的自增長列(如int 或bigint)

◆一個不斷增長的日期列(date而不是datetime)，緊跟著一個惟一的行標識（如自增長列）組成一個復合鍵，這對基于日期分區的表非常有 用。如SalesDate(8字 節）+SalesNumber(4字節）組合為12字節，注意在SQL Server 2008中，一個日期列(date)不包含時間。但是單獨的一個日期列(date)并不是一個好的聚集鍵，因為它不惟一。

◆一個GUID能被成功地用作一個聚集鍵，因為它本身就是惟一的。相對的窄(12字節）,可能是靜態的。然而，僅僅在不斷增長的模式下，GUID 才適合被用作聚集健。在一些情況下，GUID是在SQL Server的外部被生成或在SQL Server內部用 NieID()生成，這種模式下產生的碎片抵消了這個列作為聚集健的作用。如果可能，請選擇NEWSEQUENTIALID()函數或選擇其他列。如果你 想用GUID作為一個主鍵，并且不是自增長的，你可以把這個列作為一個非聚集索引代替聚集索引。

總之，沒有一個通用的最好的絕對有效的法則來決定一個聚集鍵的選擇。然而，一個表如果只有一個索引，并且是非聚集索引，那么在聚集健上的非聚集索引 依賴將不再相關。如果是聚集索引，可以采取任何形式。幸運的是，大多數表有一個以上的非聚集索引，大多數的表有一個聚集索引性能更佳。因此，第一步：精心 選擇聚集鍵，第二步，查找一個正確的平衡，選擇適當的，最小數量的非聚集索引。

非聚集索引 （NonClustering Indexes)

正如前面所述，所有索引中有兩類主要組件：葉級(leaf level)和非葉級(non-leaf Level(s)) 。一個聚集索引的葉級就是數據。一個非聚集索引葉級是一個獨立的、額外的結構（一些數據的copy),特別地，一個非聚集索引取決于它的葉級形式的定義， 非聚集索引由索引鍵，任何包含性列、數據行的書簽(bookmark)值,,一個蜚聚集索引的數量跟表中的數據行一樣多，除非索引定義時使用了過濾謂詞 (Filter predicate)。過濾謂詞在SQl Server 2008是新增的。

非聚集索引的工作方式有兩種：

１、輔助指向數據或直接回答查詢。當一個非聚集索引擁有查詢中請求的全部數據時，這就是所謂的“查詢覆蓋(query covering)”，這時索引被稱為覆蓋索引，此時，非聚集索引被用于直接回答查詢而避免了書簽查詢(bookmark lookup)，一種對于非聚集索引異常昂貴的查詢。

２、當一個非聚集索引沒有包含查詢中請求的全部數據時，這個查詢被一個索引能找到的謂詞驅動，此時，書簽查詢發生。如果一個表有一個聚集索引，非聚 集索引被用于驅動查詢去通過聚集鍵找到相應的數據行。如果是Heap(沒有聚集索引），查詢值是一個8字節的RID，實際行位置如下格式 FileID:PageID:SlotNumber。這個8字節值：2字節:4字節:2字節。后面還有深入了解。

非聚集索引的設置與否并不會影響數據頁被組織。SQL Server　2008中，一個表中可以有999個非聚集索引。SQL Server 2005中是249個。實際使用環境中，你盡可能少數量的使用（因為一些錯誤，比如Filtered Indexes）。

總而言之，非聚集索引不會影響基表，相反，基表的結構會影響非聚集索引的結構。如果你想減少開銷和架構最佳性能，你最好理解這些。

約束和索引(Constaits and Indexes)

有關Primary Key約束和UNIQUE 約束，請查看MSDN:

http://msdn.microsoft.com/zh-cn/library/ms191236.aspx

http://msdn.microsoft.com/zh-cn/library/ms191166.aspx

一個基本的區別是后者可以是NUll,前者不允許NUll,兩者都不允許重復。

Indexes Creation Options

CREATE INDEX命令的更多選項，請查看MSDN:

http://msdn.microsoft.com/zh-cn/library/ms188783.aspx