sql server提供了兩種索引：聚集索引和非聚集索引。其中聚集索引表示表中儲存的資料按照索引的順序儲存，檢索效率比非聚集索引高，但對資料更新影響較大。非聚集索引表示資料儲存在乙個地方，索引儲存在另乙個地方，索引帶有指標指向資料的儲存位置，非聚集索引檢索效率比聚集索引低，但對資料更新影響較小。
方法/步驟
聚集索引：該索引中鍵值的邏輯順序決定了表中相應行的物理順序。
聚集索引確定表中資料的物理順序。聚集索引類似於**簿，後者按姓氏排列資料。由於聚集索引規定資料在表中的物理儲存順序，因此乙個表只能包含乙個聚集索引。但該索引可以包含多個列(組合索引)，就像**簿按姓氏和名字進行組織一樣。
聚集索引使用注意事項
定義聚集索引鍵時使用的列越少越好。
61 包含大量非重複值的列。
.61 使用下列運算子返回乙個範圍值的查詢：between、>、>=、< 和 <=。
61 被連續訪問的列。
61 回大型結果集的查詢。
61 經常被使用聯接或 group by 子句的查詢訪問的列;一般來說，這些是外來鍵列。對 order by 或 group by 子句中指定的列進行索引，可以使 sql server 不必對資料進行排序，因為這些行已經排序。這樣可以提高查詢效能。
61 oltp 型別的應用程式，這些程式要求進行非常快速的單行查詢(一般通過主鍵)。應在主鍵上建立聚集索引。
聚集索引不適用於：
61 頻繁更改的列。這將導致整行移動(因為 sql server 必須按物理順序保留行中的資料值)。這一點要特別注意，因為在大資料量事務處理系統中資料是易失的。
61 寬鍵 。來自聚集索引的鍵值由所有非聚集索引作為查詢鍵使用，因此儲存在每個非聚集索引的葉條目內。
非聚集索引：資料儲存在乙個地方，索引儲存在另乙個地方，索引帶有指標指向資料的儲存位置。
非聚集索引中的專案按索引鍵值的順序儲存，而表中的資訊按另一種順序儲存(這可以由聚集索引規定)。對於非聚集索引，可以為在表非聚集索引中查詢資料時常用的每個列建立乙個非聚集索引。有些書籍包含多個索引。例如，一本介紹園藝的書可能會包含乙個植物通俗名稱索引，和乙個植物學名索引，因為這是讀者查詢資訊的兩種最常用的方法。
乙個通俗的舉例，說明兩者的區別
其實，我們的漢語字典的正文本身就是乙個聚集索引。比如，我們要查「安」字，就會很自然地翻開字典的前幾頁，因為「安」的拼音是「an」，而按照拼音排序漢字的字典是以英文本母「a」開頭並以「z」結尾的，那麼「安」字就自然地排在字典的前部。如果您翻完了所有以「a」開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字;同樣的，如果查「張」字，那您也會將您的字典翻到最後部分，因為「張」的拼音是「zhang」。也就是說，字典的正文部分本身就是乙個目錄，您不需要再去查其他目錄來找到您需要找的內容。我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為「聚集索引」。
如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據「偏旁部首」查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合「部首目錄」和「檢字表」而查到的字的排序並不是真正的正文的排序方法，比如您查「張」字，我們可以看到在查部首之後的檢字表中「張」的頁碼是672頁，檢字表中「張」的上面是「馳」字，但頁碼卻是63頁，「張」的下面是「弩」字，頁面是390頁。很顯然，這些字並不是真正的分別位於「張」字的上下方，現在您看到的連續的「馳、張、弩」三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的對映。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為「非聚集索引」。
何時使用聚集索引或非聚集索引：
下面說說索引使用的幾個誤區和問題
第一：聚集索引的約束是唯一性，是否要求欄位也是唯一的呢?
分析：如果認為是的朋友，可能是受系統預設設定的影響，一般我們指定乙個表的主鍵，如果這個表之前沒有聚集索引，同時建立主鍵時候沒有強制指定使用非聚集索引，sql會預設在此字段上建立乙個聚集索引，而主鍵都是唯一的，所以理所當然的認為建立聚集索引的字段也需要唯一。
結論：聚集索引可以建立在任何一列你想建立的字段上，這是從理論上講，實際情況並不能隨便指定，否則在效能上會是惡夢。
第二：主鍵就是聚集索引
這樣有時會對聚集索引的一種浪費。雖然sql server預設是在主鍵上建立聚集索引的。但是由於聚集索引的優勢是很明顯的，而每個表中只能有乙個聚集索引的規則，這使得聚集索引變得更加珍貴。
從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大好處就是能夠根據查詢要求，迅速縮小查詢範圍，避免全表掃瞄。在實際應用中，因為 id號是自動生成的，我們並不知道每條記錄的id號，所以我們很難在實踐中用id號來進行查詢。這就使讓id號這個主鍵作為聚集索引成為一種資源浪費。其次，讓每個id號都不同的字段作為聚集索引也不符合「大數目的不同值情況下不應建立聚合索引」規則;當然，這種情況只是針對使用者經常修改記錄內容，特別是索引項的時候會負作用，但對於查詢速度並沒有影響。
第三：是不是聚集索引就一定要比非聚集索引效能優呢?
如果想查詢學分在60-90之間的學生的學分以及姓名，在學分上建立聚集索引是否是最優的呢?
答：否。既然只輸出兩列，我們可以在學分以及學生姓名上建立聯合非聚集索引，此時的索引就形成了覆蓋索引，即索引所儲存的內容就是最終輸出的資料，這種索引在比以學分為聚集索引做查詢效能更好。
第四：在資料庫中通過什麼描述聚集索引與非聚集索引的?
索引是通過二叉樹的形式進行描述的，我們可以這樣區分聚集與非聚集索引的區別：聚集索引的葉節點就是最終的資料節點，而非聚集索引的葉節仍然是索引節點，但它有乙個指向最終資料的指標。
第五：在主鍵是建立聚集索引的表在資料插入上為什麼比主鍵上建立非聚集索引表速度要慢?
有了上面第四點的認識，我們分析這個問題就有把握了，在有主鍵的表中插入資料行，由於有主鍵唯一性的約束，所以需要保證插入的資料沒有重複。我們來比較下主鍵為聚集索引和非聚集索引的查詢情況：聚集索引由於索引葉節點就是資料頁，所以如果想檢查主鍵的唯一性，需要遍歷所有資料節點才行，但非聚集索引不同，由於非聚集索引上已經包含了主鍵值，所以查詢主鍵唯一性，只需要遍歷所有的索引頁就行，這比遍歷所有資料行減少了不少io消耗。這就是為什麼主鍵上建立非聚集索引比主鍵上建立聚集索引在插入資料時要快的真正原因。
聚集索引 和 非聚集索引區別
一.mysql的索引 mysql中，不同的儲存引擎對索引的實現方式不同，大致說下myisam和innodb兩種儲存引擎。myisam的b tree的葉子節點上的data，並不是資料本身，而是資料存放的位址。主索引和輔助索引沒啥區別，只是主索引中的key一定得是唯一的。這裡的索引都是非聚簇索引。myi...
聚集索引和非聚集索引區別
聚集索引 資料行的物理順序與列值 一般是主鍵那一列 的邏輯順序相同，乙個表只能擁有乙個聚集索引！非聚集索引 該索引中索引的邏輯順序與磁碟上行的物理順序不同乙個表可以擁有多個非聚集索引！非聚集索引可細分成普通索引，唯一索引，全文索引 區別 聚集索引 可以幫助把很大的範圍，迅速減小範圍。但是查詢該記錄，...
聚集索引和非聚集索引的區別
暫且摘錄如下 摘錄1 前者加在不常更新的表，後者加在經常更新的表 摘錄2 使用聚集索引 聚集索引確定表中資料的物理順序。聚集索引類似於 簿，後者按姓氏排列資料。由於聚集索引規定資料在表中的物理儲存順序，因此乙個表只能包含乙個聚集索引。但該索引可以包含多個列 組合索引 就像 簿按姓氏和名字進行組織一樣...