聚集索引並不是一個單獨的索引類型，實際上是一種數據存儲的方式。聚集索引的實現細節各有不同，在InnoDB引擎中，聚集索引實際上是將索引和數據行使用同樣的結構存儲在一個二叉樹中。
如果數據表中有聚集索引，則數據行實際上是存在所以的葉子節點。“聚集”的形式實際是指相鄰鍵值的數據行是鄰近存儲的。因爲一行數據不能存儲在兩個葉子節點上，因此在數據表中只能有一個聚集索引。由於是存儲引擎負責索引的實現，因此並不是全部的存儲引擎都支持聚集索引。在這裏我們只討論InnoDB，但支持聚集索引的存儲引擎實現聚集索引的原理都大同小異。
下圖展示了數據記錄在聚集索引的存儲佈局。注意，葉子節點包含了完整的數據行，而其他節點僅僅只有索引。在這個圖中，索引列使用的是整數。
有些數據庫服務器允許我們選擇對哪個索引進行聚集，但MySQL的任意內置的存儲引擎都不支持這麼做。InnoDB使用主鍵對數據進行聚集，這意味着上圖的索引列實際上是主鍵列。
如果數據表沒有定義主鍵，InnoDB會選擇使用唯一的非空列（Not Null）索引替代。如果沒有這樣的索引，InnoDB會定義一個隱藏的主鍵去完成數據聚集（因此，數據表最好自己定義主鍵）。InnoDB的只能在一個數據頁中進行數據聚集，因此即便是臨近的索引值的數據存儲頁也可能間隔很遠。
一個聚集主鍵能夠提高性能，但同樣也可能導致嚴重的性能問題。因此，你應當謹慎考慮聚集的使用，尤其是當你將一個數據表的存儲引擎從InnoDB改爲其他引擎時。
聚集索引具有如下的優勢：
- 可以將相關聯的數據行保持鄰近存儲。例如，郵箱應用中，你可以使用user_id進行聚集。這種情況下，你可以從磁盤的很少的分頁中獲取用戶的全部消息。而如果不使用聚集索引，每條消息都可能需要單獨佔用磁盤I/O。
- 數據訪問很快：聚集索引將索引和數據同時存儲在二叉樹中，因此從聚集索引中獲取數據行比起非聚集索引的查詢來說快很多。
- 使用了覆蓋索引的查詢可以利用主鍵中包含在葉子節點的數據值。
如果你在設計數據表和查詢時充分利用這些好處，將能顯著提升性能。然而，聚集索引也有缺點：
- 聚集能對受限於I/O負載的情況很大改善，但如果數據是在內存而與磁盤無關，那聚集實際上幫不上什麼忙。
- 插入速度嚴重依賴插入次序。按照主鍵順序插入數據是InnoDB表中最快的方式，如果加載數據不是按照主鍵次序，那在完成大量數據的加載後，最好是使用優化表（OPTIMIZE TABLE）功能重新組織一下數據表。
- 更新聚集索引列的代價很高，因爲這會強制InnoDB去移動更新的數據行到一個新的位置。
- 當新的數據行插入時或行的主鍵更新引起數據行移動，數據表已經構建的聚集索引會分頁（page split）。分頁情況發生在新的數據行需要移入一個放滿數據的存儲頁時。存儲引擎必須將存儲頁分成兩部分去存儲新的行，這會導致數據表佔用更多的磁盤空間。
- 聚集表在全表掃描時可能會更慢，尤其是數據行密集度不高或者是因爲分頁導致存儲不連續。
- 非聚集索引（Secondary Index）會比你預期的存儲要大，這是因爲葉子節點包含了主鍵列引用的數據行。
- 非聚集索引訪問時需要兩次索引查找而不是一次。這個可能感覺有點費解，其原因在於非聚集索引存儲的是數據行指針。記住，葉子節點並並不是存儲引用行的實際物理位置，而是該行的主鍵值。這意味着，使用非聚集索引查詢數據行時，存儲引擎首先通過非聚集索引找到其葉子節點，然後通過葉子節點的主鍵再找到數據行的值。這相當於進行了兩次二叉樹的查找，在InnoDB中，自適應的哈希索引可以減少這種概率。
InnoDB和MyISAM數據佈局比較
聚集和非聚集數據佈局，以及主鍵和非聚集索引的差別可能讓人困惑和奇怪。我們可以比較一下InnoDB和MyISAM對下面數據表的存儲佈局來深入瞭解一下。
CREATE TABLE layout_test (
col1 int NOT NULL,
col2 int NOT NULL,
PRIMARY KEY(col1),
KEY(col2)
);
假設這個表產生了主鍵1到10000的數據，採用的是隨機順序插入的，然後在通過OPTIMIZE TABLE進行了優化。換言之，數據在磁盤上是有序排列的，但行可能是隨機順序的。數據列col2使用1-100的隨機值填充，因此存在很多的重複值。
MyISAM的數據佈局更簡單些，MyISAM按照插入的順序在磁盤存儲數據，如下圖所示。我們以0開始展示了數據行編號，由於每一行的大小是固定的，MyISAM可以從表最開始的地方根據所需要的字節數來找到任意行（MyISAM內部並不總是使用行號，而是根據行是否固定大小或可變大小使用不同的策略）。
這種結構使其很容易構建索引，下圖繪製了一個數據系列，這個圖中，物理的細節（例如存儲頁）被抽象隱藏，在索引中只有節點。每個索引的葉子節點可以簡單地包含對應的行號，在下圖是其主鍵。在這裏隱藏了一些細節，例如在前一個節點後有少個內部的二叉樹節點，但這對於理解非聚集存儲引擎基礎的數據佈局來說並不重要。
那對於col2列的索引怎麼樣。實際上，它和其他索引一樣。
事實上，在MyISAM中，主鍵和其他索引並沒有結構上的區別。主鍵只是一個簡單的唯一、不爲空的索引，僅僅是名字命名爲主鍵而已。
InnoDB由於聚集索引的組織方式，存儲同樣數據的結構十分不同，如下圖所示。
初看這張圖，感覺似乎和MyISAM的並無太大不同，但是仔細再看一遍，實際上這個圖展示了整張數據表，而不只是索引。由於聚集索引在InnoDB中已經是整張表了，因此這裏沒有像在MyISAM中的獨立的行存儲。
InnoDB的聚集索引每個葉子節點都包含主鍵值、事務ID、回滾指針以便進行事務和MVCC（Multi Version Cocurrent Control, 併發多版本控制），以及剩下的其他列（示例數據表就是col2）。如果主鍵作用在一個列的前綴上，InnoDB會在其他列中包含主鍵列的完整值。
同樣，與MyISAM相比，非聚集索引和聚集索引有很大不同。相比於存儲行指針，InnoDB非聚集索引的葉子節點存儲的是主鍵值，由主鍵再指向數據。這個策略在行移動或數據分頁需要維護非聚集索引時，減少了很多工作。使用行主鍵值作爲指針意味着索引更大，但也意味着InnoDB可以移動行而不需要去更新非聚集索引的指針。下圖展示了非聚集索引的數據佈局，可以看到非聚集索引實際上存儲了主鍵的值。
這些圖展示了二叉樹的葉子節點，但是我們隱藏了非葉子節點的細節。InnoDB中非葉子節點的二叉樹的每一個節點都包含索引列，並另外附加了下一個層級的節點的指針（有可能是非葉子節點也可能是葉子節點）。這個對聚集索引和非聚集索引都一樣。下圖展示了InnoDB和MyISAM的索引的抽象結構對比，從中可以看出二者的不同之處。