SQL Server 叢集索引和非叢集索引的區別

叢集索引:實體儲存體按照索引排序
非叢集索引:實體儲存體不按照索引排序

優勢與缺點
叢集索引：插入資料時速度要慢（時間花費在“實體儲存體的排序”上，也就是首先要找到位置然後插入）
                 查詢資料比非聚集資料的速度快

               漢語字典的本文本身就是一個叢集索引。
比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因為“安”的拼音是“an”，而按照拼音排序漢字的字典是以英文字母“a”開頭並以“z”結尾
的，那麼“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字；同樣的，如果查“張”
字，那您也會將您的字典翻到最後部分，因為“張”的拼音是“zhang”。也就是說，字典的本文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需
要找的內容。本文內容本身就是一種按照一定規則排列的目錄稱為“叢集索引”。
   

如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而
需要去根據“偏旁部首”查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的排序並不是
真正的本文的排序方法，比如您查“張”字，我們可以看到在查部首之後的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63
頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字並不是真正的分別位於“張”字的上下方，現在您看到的連續的“馳、張、弩”三字實際上就是他
們在非叢集索引中的排序，是字典本文中的字在非叢集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。我們把這種目錄純粹是目錄，本文純粹是本文的排序方式稱為“非叢集索引”。
    通過以上例子，我們可以理解到什麼是“叢集索引”和“非叢集索引”。
進一步引申一下，我們可以很容易的理解：每個表只能有一個叢集索引，因為目錄只能按照一種方法進行排序。得出查詢速度的方法是：在各個select語句前加：declare @d datetime

set @d=getdate()

並在select語句後加：

select [語句執行花費時間(毫秒)]=datediff(ms,@d,getdate())

1、用彙總索引比用不是彙總索引的主鍵速度快

2、用彙總索引比用一般的主鍵作order by時速度快，特別是在小資料量情況下
      事實上，如果資料量很小的話，用叢集索引作為排序列要比使用非叢集索引速度快得明顯的多；而資料量如果很大的話，如10萬以上，則二者的速度差別不明顯。

3、使用彙總索引內的時間段，搜尋時間會按資料占整個資料表的百分比成比例減少，而無論彙總索引使用了多少個

4 、日期列不會因為有分秒的輸入而減慢查詢速度

從publish 表中取出第 n 條到第 m 條的記錄：
SELECT TOP m-n+1 *
FROM publish
WHERE (id NOT IN
　　　　(SELECT TOP n-1 id
　　　　 FROM publish))

id 為publish 表的關鍵字

只所以把“查詢最佳化”和“分頁演算法”這兩個聯絡不是很大的論題放在一起，就是因為二者都需要一個非常重要的東西――叢集索引。

在前面的討論中我們已經提到了，叢集索引有兩個最大的優勢：

1、以最快的速度縮小查詢範圍。

2、以最快的速度進列欄位排序。

第1條多用在查詢最佳化時，而第2條多用在進行分頁時的資料排序。
      而叢集索引在每個表內又只能建立一個，這使得叢集索引顯得更加的重要。叢集索引的挑選可以說是實現“查詢最佳化”和“高效分頁”的最關鍵因素。
      但要既使叢集索引列既符合查詢列的需要，又符合排序列的需要，這通常是一個矛盾。

叢集索引是如此的重要和珍貴，所以一定要將叢集索引建立在：

1、您最頻繁使用的、用以縮小查詢範圍的欄位上；

2、您最頻繁使用的、需要排序的欄位上。

二）何時使用叢集索引或非叢集索引

下面的表總結了何時使用叢集索引或非叢集索引（很重要）。

動作描述	使用叢集索引	使用非叢集索引
列經常被分組排序	應	應
返回某範圍內的資料	應	不應
一個或極少不同值	不應	不應
小數目的不同值	應	不應
大數目的不同值	不應	應
頻繁更新的列	不應	應
外鍵列	應	應
主鍵列	應	應
頻繁修改索引列	不應	應

 

每個表中只能有一個叢集索引的規則。