以一本英文課本為例，要找第8課，直接翻書，若先翻到第5課，則往後翻，再翻到第10課，則又往前翻。這本書本身就是乙個索引，即「聚簇索引」。
如果要找"fire」這個單詞，會翻到書後面的附錄，這個附錄是按字母排序的，找到f字母那一塊，再找到"fire」，對應的會是它在第幾課。這個附錄，為「非聚簇索引」。
由此可見，聚簇索引，索引的順序就是資料存放的順序，所以，很容易理解，一張資料表只能有乙個聚簇索引。
聚簇索引要比非聚簇索引查詢效率高很多，特別是範圍查詢的時候。所以，至於聚簇索引到底應該為主鍵，還是其他字段，這個可以再討論。
1、mysql的索引
mysql中，不同的儲存引擎對索引的實現方式不同，大致說下myisam和innodb兩種儲存引擎。
myisam的b+tree的葉子節點上的data，並不是資料本身，而是資料存放的位址。主索引和輔助索引沒啥區別，只是主索引中的key一定得是唯一的。這裡的索引都是非聚簇索引。
myisam還採用壓縮機制儲存索引，比如，第乙個索引為「her」，第二個索引為「here」，那麼第二個索引會被儲存為「3,e」，這樣的缺點是同乙個節點中的索引只能採用順序查詢。
innodb的資料檔案本身就是索引檔案，b+tree的葉子節點上的data就是資料本身，key為主鍵，這是聚簇索引。非聚簇索引，葉子節點上的data是主鍵(所以聚簇索引的key，不能過長)。為什麼存放的主鍵，而不是記錄所在位址呢，理由相當簡單，因為記錄所在位址並不能保證一定不會變，但主鍵可以保證。
至於為什麼主鍵通常建議使用自增id呢？
2、聚簇索引
聚簇索引的資料的物理存放順序與索引順序是一致的，即：只要索引是相鄰的，那麼對應的資料一定也是相鄰地存放在磁碟上的。如果主鍵不是自增id，那麼可以想象，它會幹些什麼，不斷地調整資料的實體地址、分頁，當然也有其他一些措施來減少這些操作，但卻無法徹底避免。但，如果是自增的，那就簡單了，它只需要一頁一頁地寫，索引結構相對緊湊，磁碟碎片少，效率也高。
聚簇索引不但在檢索上可以大大滴提高效率，在資料讀取上也一樣。比如：需要查詢f~t的所有單詞。
乙個使用myisam的主索引，乙個使用innodb的聚簇索引。兩種索引的b+tree檢索時間一樣，但讀取時卻有了差異。
因為myisam的主索引並非聚簇索引，那麼他的資料的實體地址必然是凌亂的，拿到這些實體地址，按照合適的演算法進行i/o讀取，於是開始不停的尋道不停的旋轉。聚簇索引則只需一次i/o。
不過，如果涉及到大資料量的排序、全表掃瞄、count之類的操作的話，還是myisam佔優勢些，因為索引所佔空間小，這些操作是需要在記憶體中完成的。
鑑於聚簇索引的範圍查詢效率，很多人認為使用主鍵作為聚簇索引太多浪費，畢竟幾乎不會使用主鍵進行範圍查詢。但若再考慮到聚簇索引的儲存，就不好定論了。
下表給出了何時使用聚簇索引與非聚簇索引:
動作使用聚簇索引
使用非聚簇索引
列經常被分組排序應應
返回某範圍內的資料應不應
乙個或極少不同值
不應不應
小數目的不同值應不應
大數目的不同值不應應
頻繁更新的列不應應
外來鍵列應
應主鍵列應應
頻繁修改索引列不應應
MySQL 聚簇索引 和 非聚簇索引
索引節點的葉子頁面就好比一片葉子。葉子頭便是索引鍵值。先建立一張表 create table user id intnot null name varchar notnull class varchar notnull 對於myisam引擎，如果建立 id 和 name 為索引。對於下面查詢 sel...
MySQL聚簇索引和非聚簇索引
聚簇索引是指葉子節點儲存的是一整行記錄，比如innodb的主鍵索引，主鍵和表資料儲存在一起。聚簇索引並不是一種單獨的索引型別，而是一種資料儲存方式，因為一行資料不能同時儲存在兩個地方，所以一張表中只能有乙個聚簇索引，因為一張表的資料儲存順序只能是一種，故只有innodb主鍵索引是聚簇索引。聚簇索引的...
聚簇索引和非聚簇索引
一 聚簇索引 clustered indexes 的使用 聚簇索引是一種對磁碟上實際資料重新組織以按指定的乙個或多個列的值排序。由於聚簇索引的索引頁面指標指向資料頁面，所以使用聚簇索引查詢資料幾 乎總是比使用非聚簇索引快。每張表只能建乙個聚簇索引，並且建聚簇索引需要至少相當該錶120 的附加空間，以...