聚集索引和非聚集索引的區別:
漢語字典的正文本身就是一個聚集索引。比如,我們要查“安”字,就會很自然地翻開字典的前幾頁,因為“安”的拼音是“an”,而按照拼音排序漢字的字典是以英文字母“a”開頭並以“z”結尾的,那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字,那么就說明您的字典中沒有這個字;同樣的,如果查“張”字,那您也會將您的字典翻到最后部分,因為“張”的拼音是“zhang”。也就是說,字典的正文部分本身就是一個目錄,您不需要再去查其他目錄來找到您需要找的內容。正文內容本身就是一種按照一定規則排列的目錄稱為“聚集索引”。
如果您認識某個字,您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字,不知道它的發音,這時候,您就不能按照剛才的方法找到您要查的字,而需要去根據“偏旁部首”查到您要找的字,然后根據這個字后的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的排序並不是真正的正文的排序方法,比如您查“張”字,我們可以看到在查部首之后的檢字表中“張”的頁碼是672頁,檢字表中“張”的上面是“馳”字,但頁碼卻是63頁,“張”的下面是“弩”字,頁面是390頁。很顯然,這些字並不是真正的分別位於“張”字的上下方,現在您看到的連續的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字,但它需要兩個過程,先找到目錄中的結果,然后再翻到您所需要的頁碼。
兩者的根本區別是表記錄的排列順序和與索引的排列順序是否一致。
1.聚集索引一個表只能有一個,而非聚集索引一個表可以存在多個。
2.聚集索引存儲記錄是物理上連續存在,而非聚集索引是邏輯上的連續,物理存儲並不連續。
3.聚集索引查詢數據速度快,插入數據速度慢;非聚集索引反之。
聚集索引和非聚集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致,
聚集索引表記錄的排列順序與索引的排列順序一致,優點是查詢速度快,因為一旦具有第一個索引值的紀錄被找到,具有連續索引值的記錄也一定物理的緊跟其后。
聚集索引的缺點是對表進行修改速度較慢,這是為了保持表中的記錄的物理順序與索引的順序一致,而把記錄插入到數據頁的相應位置,必須在數據頁中進行數據重排,降低了執行速度。
非聚集索引指定了表中記錄的邏輯順序,但記錄的物理順序和索引的順序不一致,聚集索引和非聚集索引都采用了B+樹的結構,但非聚集索引的葉子層並不與實際的數據頁相重疊,而采用葉子層包含一個指向表中的記錄在數據頁中的指針的方式。非聚集索引比聚集索引層次多,添加記錄不會引起數據順序的重組。
聚集索引:物理存儲按照索引排序
非聚集索引:物理存儲不按照索引排序
聚集索引在插入數據時速度要慢(時間花費在“物理存儲的排序”上,也就是首先要找到位置然后插入),但查詢數據比非聚集數據的速度快
--------------------
SQL SERVER提供了兩種索引:聚集索引和非聚集索引。其中聚集索引表示表中存儲的數據按照索引的順序存儲,檢索效率比非聚集索引高,但對數據更新影響較大。非聚集索引表示數據存儲在一個地方,索引存儲在另一個地方,索引帶有指針指向數據的存儲位置,非聚集索引檢索效率比聚集索引低,但對數據更新影響較小。
-
聚集索引確定表中數據的物理順序。聚集索引類似於電話簿,后者按姓氏排列數據。由於聚集索引規定數據在表中的物理存儲順序,因此一個表只能包含一個聚集索引。但該索引可以包含多個列(組合索引),就像電話簿按姓氏和名字進行組織一樣。
-
定義聚集索引鍵時使用的列越少越好。
• 包含大量非重復值的列。
.• 使用下列運算符返回一個范圍值的查詢:BETWEEN、>、>=、< 和 <=。
• 被連續訪問的列。
• 回大型結果集的查詢。
• 經常被使用聯接或 GROUP BY 子句的查詢訪問的列;一般來說,這些是外鍵列。對 ORDER BY 或 GROUP BY 子句中指定的列進行索引,可以使 SQL Server 不必對數據進行排序,因為這些行已經排序。這樣可以提高查詢性能。
• OLTP 類型的應用程序,這些程序要求進行非常快速的單行查找(一般通過主鍵)。應在主鍵上創建聚集索引。
-
• 頻繁更改的列 。這將導致整行移動(因為 SQL Server 必須按物理順序保留行中的數據值)。這一點要特別注意,因為在大數據量事務處理系統中數據是易失的。
• 寬鍵 。來自聚集索引的鍵值由所有非聚集索引作為查找鍵使用,因此存儲在每個非聚集索引的葉條目內。
-
非聚集索引中的項目按索引鍵值的順序存儲,而表中的信息按另一種順序存儲(這可以由聚集索引規定)。對於非聚集索引,可以為在表非聚集索引中查找數據時常用的每個列創建一個非聚集索引。有些書籍包含多個索引。例如,一本介紹園藝的書可能會包含一個植物通俗名稱索引,和一個植物學名索引,因為這是讀者查找信息的兩種最常用的方法。
-
其實,我們的漢語字典的正文本身就是一個聚集索引。比如,我們要查“安”字,就會很自然地翻開字典的前幾頁,因為“安”的拼音是“an”,而按照拼音排序漢字的字典是以英文字母“a”開頭並以“z”結尾的,那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字,那么就說明您的字典中沒有這個字;同樣的,如果查“張”字,那您也會將您的字典翻到最后部分,因為“張”的拼音是“zhang”。也就是說,字典的正文部分本身就是一個目錄,您不需要再去查其他目錄來找到您需要找的內容。我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為“聚集索引”。
如果您認識某個字,您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字,不知道它的發音,這時候,您就不能按照剛才的方法找到您要查的字,而需要去根據“偏旁部首”查到您要找的字,然后根據這個字后的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的排序並不是真正的正文的排序方法,比如您查“張”字,我們可以看到在查部首之后的檢字表中“張”的頁碼是672頁,檢字表中“張”的上面是“馳”字,但頁碼卻是63頁,“張”的下面是“弩”字,頁面是390頁。很顯然,這些字並不是真正的分別位於“張”字的上下方,現在您看到的連續的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字,但它需要兩個過程,先找到目錄中的結果,然后再翻到您所需要的頁碼。我們把這種目錄純粹是目錄,正文純粹是正文的排序方式稱為“非聚集索引”。
-
-
第一:聚集索引的約束是唯一性,是否要求字段也是唯一的呢?
分析:如果認為是的朋友,可能是受系統默認設置的影響,一般我們指定一個表的主鍵,如果這個表之前沒有聚集索引,同時建立主鍵時候沒有強制指定使用非聚集索引,SQL會默認在此字段上創建一個聚集索引,而主鍵都是唯一的,所以理所當然的認為創建聚集索引的字段也需要唯一。
結論:聚集索引可以創建在任何一列你想創建的字段上,這是從理論上講,實際情況並不能隨便指定,否則在性能上會是惡夢。
第二:主鍵就是聚集索引
這樣有時會對聚集索引的一種浪費。雖然SQL SERVER默認是在主鍵上建立聚集索引的。但是由於聚集索引的優勢是很明顯的,而每個表中只能有一個聚集索引的規則,這使得聚集索引變得更加珍貴。
從我們前面談到的聚集索引的定義我們可以看出,使用聚集索引的最大好處就是能夠根據查詢要求,迅速縮小查詢范圍,避免全表掃描。在實際應用中,因為 ID號是自動生成的,我們並不知道每條記錄的ID號,所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。其次,讓每個ID號都不同的字段作為聚集索引也不符合“大數目的不同值情況下不應建立聚合索引”規則;當然,這種情況只是針對用戶經常修改記錄內容,特別是索引項的時候會負作用,但對於查詢速度並沒有影響。
第三:是不是聚集索引就一定要比非聚集索引性能優呢?
如果想查詢學分在60-90之間的學生的學分以及姓名,在學分上創建聚集索引是否是最優的呢?
答:否。既然只輸出兩列,我們可以在學分以及學生姓名上創建聯合非聚集索引,此時的索引就形成了覆蓋索引,即索引所存儲的內容就是最終輸出的數據,這種索引在比以學分為聚集索引做查詢性能更好。
第四:在數據庫中通過什么描述聚集索引與非聚集索引的?
索引是通過二叉樹的形式進行描述的,我們可以這樣區分聚集與非聚集索引的區別:聚集索引的葉節點就是最終的數據節點,而非聚集索引的葉節仍然是索引節點,但它有一個指向最終數據的指針。
第五:在主鍵是創建聚集索引的表在數據插入上為什么比主鍵上創建非聚集索引表速度要慢?
有了上面第四點的認識,我們分析這個問題就有把握了,在有主鍵的表中插入數據行,由於有主鍵唯一性的約束,所以需要保證插入的數據沒有重復。我們來比較下主鍵為聚集索引和非聚集索引的查找情況:聚集索引由於索引葉節點就是數據頁,所以如果想檢查主鍵的唯一性,需要遍歷所有數據節點才行,但非聚集索引不同,由於非聚集索引上已經包含了主鍵值,所以查找主鍵唯一性,只需要遍歷所有的索引頁就行,這比遍歷所有數據行減少了不少IO消耗。這就是為什么主鍵上創建非聚集索引比主鍵上創建聚集索引在插入數據時要快的真正原因。
聚集索引:物理存儲按照索引排序
非聚集索引:物理存儲不按照索引排序
聚集索引在插入數據時速度要慢(時間花費在“物理存儲的排序”上,也就是首先要找到位置然后插入),但查詢數據比非聚集數據的速度快
索引是通過二叉樹的數據結構來描述的,我們可以這么理解聚簇索引:索引的葉節點就是數據節點。而非聚簇索引的葉節點仍然是索引節點,只不過有一個指針指向對應的數據塊。轉自:http://www.cnblogs.com/lenther2002/p/6763336.html