聚集索引不是一種單獨的索引型別，而是一種儲存資料方式。其具體細節依賴於實現方式，但是InnoDB的聚集索引實際上在同樣的結構中儲存了B-Tree索引和資料行。

當表有聚集索引的時候，它的資料行實際儲存在索引的葉子頁中。術語“聚集”指實際的資料行和相關的鍵值都儲存在一起。每個表只能有一個聚集索引，因為不能一次把行儲存在兩個地方。（但是，覆蓋索引可以模擬多個聚集索引）

當前，SolidDB和InnoDB是唯一支援聚集索引的儲存引擎。InnoDB按照主鍵進行聚集，如果沒有定義主鍵，InnoDB會試著使用唯一的非空索引來代替。如果沒有這種索引，InnoDB就會定義隱藏的主鍵然後在上面進行聚集。

聚集主鍵有助於效能，但是它也能導致嚴重的效能問題。

優點：

1.可以把相關資料儲存在一起。

2.資料訪問快。聚集索引把索引和資料都儲存到同一棵B-Tree中，因此從聚集索引中取得資料通常在非聚集索引進行查詢要快。

3.使用覆蓋索引的查詢可以使用包含在葉子節點中的主鍵值

如果表和查詢可以使用它們，這些優點能極大地提高效能。

缺點：

1.聚集能最大限度地提升I/O密集負載的效能。如果資料能裝入記憶體，那麼其順序也就無怕謂了，這樣聚集就沒什麼用處。

2.插入速度嚴重依賴於插入順序。按照主鍵的順序插入行是把資料裝入InnoDB表最快的方法。如果沒有按照主鍵順序插入資料，那麼在插入之後最好使用OPTIMIZE TABLE重新組織一下表。

3.更新聚集索引列是昂貴的，因為它強制InnoDB把每個更新的遷移到新的位置。

3.建立在聚集索引上的表在插入新行，或者在行的主鍵被更新，該行必須被移動的時候會進行分頁。分佈發生在行的鍵值要求行必須被放到一個已經放滿了資料的頁的時候，此時儲存引擎必須分頁才能容納該行。分頁會導致表佔用更多的磁碟空間

4.聚集表可能會比全表掃描慢，尤其在表儲存得比較稀疏或因為分頁而沒有順序儲存的時候。

5.第二（非聚集）索引可能會比預想的大，因為它們的葉子節點包含了被引用行的主鍵列。

6.第二索引訪問需要兩次索引查詢，而不是一次（葉子節點不會儲存引用的行的物理位置，而是保持了行的主鍵值）

這意味著為了從第二索引查詢行，儲存引擎首先要找到葉子，然後使用儲存在那裡的主鍵值找到主鍵。最終找到行。這需要兩次動作，兩次B-Tree導航（在InnoDB中，自適應雜湊索引能減少這種損失）

如果正在使用InnoDB並且不需要任何特定的聚集，就可以定義一個代理鍵。它是一種主鍵，但是值和應用程式無關。最簡單的方法是使用AUTO_INCREMENT列。這會是順序插入的並且能提高使用主鍵聯接的效能，減少分頁和碎片產生。