聚集索引:物理存儲按照索引排序
非聚集索引:物理存儲不按照索引排序
優(yōu)勢與缺點(diǎn)
聚集索引：插入數(shù)據(jù)時速度要慢（時間花費(fèi)在“物理存儲的排序”上，也就是首先要找到位置然后插入）
查詢數(shù)據(jù)比非聚集數(shù)據(jù)的速度快

漢語字典的正文本身就是一個聚集索引。比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因?yàn)椤鞍病钡钠匆羰恰癮n”，而按照拼音排序漢字的字典是以英文字母“a”開頭并以“z”結(jié)尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字，那么就說明您的字典中沒有這個字；同樣的，如果查“張” 字，那您也會將您的字典翻到最后部分，因?yàn)椤皬垺钡钠匆羰恰皕hang”。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內(nèi)容。正文內(nèi)容本身就是一種按照一定規(guī)則排列的目錄稱為“聚集索引”。
    如果您認(rèn)識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認(rèn)識的字，不知道它的發(fā)音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據(jù)“偏旁部首”查到您要找的字，然后根據(jù)這個字后的頁碼直接翻到某頁來找到您要找的字。但您結(jié)合“部首目錄”和“檢字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“張”字，我們可以看到在查部首之后的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63 頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字并不是真正的分別位于“張”字的上下方，現(xiàn)在您看到的連續(xù)的“馳、張、弩”三字實(shí)際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結(jié)果，然后再翻到您所需要的頁碼。我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為“非聚集索引”。
    通過以上例子，我們可以理解到什么是“聚集索引”和“非聚集索引”。
進(jìn)一步引申一下，我們可以很容易的理解：每個表只能有一個聚集索引，因?yàn)槟夸浿荒馨凑找环N方法進(jìn)行排序。得出查詢速度的方法是：在各個select語句前加：declare @d datetime

set @d=getdate()

并在select語句后加：

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

1、用聚合索引比用不是聚合索引的主鍵速度快

2、用聚合索引比用一般的主鍵作order by時速度快，特別是在小數(shù)據(jù)量情況下
      事實(shí)上，如果數(shù)據(jù)量很小的話，用聚集索引作為排序列要比使用非聚集索引速度快得明顯的多；而數(shù)據(jù)量如果很大的話，如10萬以上，則二者的速度差別不明顯。

3、使用聚合索引內(nèi)的時間段，搜索時間會按數(shù)據(jù)占整個數(shù)據(jù)表的百分比成比例減少，而無論聚合索引使用了多少個

4 、日期列不會因?yàn)橛蟹置氲妮斎攵鴾p慢查詢速度

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

id 為publish 表的關(guān)鍵字

只所以把“查詢優(yōu)化”和“分頁算法”這兩個聯(lián)系不是很大的論題放在一起，就是因?yàn)槎叨夹枰粋€非常重要的東西