聚簇索引並不是一種單獨的索引類型，而是一種數據存儲方式。具體的細節依賴於其實現方式，但innoddb 的聚簇索引實際上在同一個結構中保存了B-Tree索引和數據行。
當表有聚簇索引時，它的數據實際上存放在索引的葉子頁（leaf page）中。術語‘聚簇’表示數據行和相鄰的鍵值進錯的存儲在一起。因為無法同時把數據行存放在兩個不同的地方，所以在一個表中只能有一個聚簇索引 （不過，覆蓋索引可以模擬多個聚簇索引的情況）。
因為存儲引擎負責實現索引，因此不是所有的存儲引擎都支持聚簇索引。
一些數據庫服務器允許選擇哪個索引作為聚簇索引，但直到本書協寫作之前，還沒有任何一個MySQL內奸的存儲引擎支持這一點。InnoDb將通過主鍵聚集數據。
如果沒有定義主鍵，InnoDB 會選擇一個唯一的非空索引代替。如果沒有這樣的索引，InnoDB 會隱式定義一個主鍵來作為聚簇索引。InnoDB值聚集在同一個頁面中的記錄。。包含相鄰鍵值的頁面可能會相距很遠。
聚簇索引可能對性能有幫助，但也可能導致嚴重的性能問題。所以需要咨詢的考慮聚簇索引，尤其是將表的存儲引擎從InnoDB 該成其他的引擎的時候（返回來也一樣）。
聚簇索引的一些重要優點：
可以吧相關的數據保存在一起。例如，實現電子郵箱時，可以根據用戶id來聚集數據這樣只需要從磁盤讀取少數的數據頁就能獲取某個用戶的全部郵件。如果沒有使用聚簇索引，則每封郵件都肯能導致一次io。
數據訪問更快。聚簇索引將索引和數據保存在同一個B-Tree中，因此從聚簇索引中獲取數據通常比非聚簇索引中快。
使用覆蓋索引掃描的查詢可以直接使用頁節點中的主鍵值。
聚簇索引的缺點：
聚簇索引最大限度的提高了io密集型應用的性能，但如果數據全部存放在內存中，則訪問的順序就沒那么重要了，聚簇索引也就沒有什么優勢了。
插入速度嚴重依賴插入順序。按照主鍵的順序插入是加載數據到innodb表中速度最快的方式。但如果不是按照主鍵順序加載數據，那么加載完成后最好使用OPTIMIZE TABLE 命令來重新組織一下表。
更新聚簇索引的代價很高，因為會強制InooDB將每個更新的數據移動到新的位置。
基於聚簇索引的表在插入行，或者主鍵被更新導致需要移動行的時候，可能面臨’頁分裂（page split）‘的問題。當行的主鍵值要求必須將這一行插入到某個已滿的頁中時。存儲引擎，存儲引擎會將該頁分裂成兩個頁面來容納該行，這就是一次頁分裂操作。頁分裂會導致表占用更多的存儲空間。
聚簇索引可能導致全表掃描變慢，尤其是行比較稀疏，或者由於頁分裂導致數據存儲不連續的時候。
二級索引（非聚簇索引）可能比想象的要更大，因為在二級索引的子節點包含了最優一個幾點可能讓人有些疑惑，為什么二級索引需要兩次索引查找？答案在於二級索引中保存的“行指針”的實質。要記住，二級索引葉子節點保存的不是只想物理位置的指針，而是行的主鍵值。
這意味着通過二級索引進行查找行，存儲引擎需要找到二級索引的子節點獲得對應的主鍵值，然后根據這個值去聚簇索引總超找到對應的行。這里做了重復的工作：兩次B-Tree查找，而不是一次。對於InnoDB，自適應哈希索引能夠減少這樣重復工作。
InnoDB 和 MyISAM的數據分布對比
聚簇索引和非聚簇索引的數據分布有區別，以及對應的主鍵索引和二級索引的數據分布也有區別，通常會讓人感到困惑和意外。來看看InnoDB和MyISAM是如何存儲下面的這個表的：
CREATE TABLE layout_test(
col1 int not null,
col2 int not null,
primary key (col1),
key(col2)
);
假設該表的主鍵取值為1-1w，按照隨機順序插入，並使用OPTIMIZE TABLE命令做了優化。換句話說，數據在磁盤的存儲方式已經最優，但進行的順序是隨機的。列col2的值時從1-100之間隨機賦值，所以有很多重復的值。
MyISAM 的數據分布.。 MyISAM的數據分布非常簡單，所以先介紹它。MyIsam按照數據插入的順序存儲在磁盤上。
實際上，MyISAM 中主鍵索引和其他索引在結構上沒有什么不同。主鍵索引就是一個名為PRIMARY的唯一非空索引。
InnoDB 的數據分布。因為InnoDB支持聚簇索引，索引使用非常不同的方式存儲同樣的數據。在InnoDB中，聚簇索引“就是”表，所以不像myISAM那樣需要獨立的行存儲。聚簇索引的每一個葉子節點都包含了主鍵值、事務id，用於事務和MVCC的回滾指針。這樣的策略減少了當前出現行移動或者數據頁分裂是二級索引的維護工作。使用主鍵值當作指針會讓二級索引占用更多的存儲空間，存儲，換來的好處是，InnoDB在移動行時，無需更新二級索引中的這個指針。InnoDB 的非葉子節點包含了索引列和一個紙箱下級節點的指針（下級節點可以是葉子節點，也可以是非葉子節點）。這對聚簇索引和二級索引都使用。
在InnoDB表中按照主鍵順序插入行
如果正在使用InnoDB 表並且沒有什么數據需要聚集，那么可以定義一個代理鍵（surrogate key）作為主鍵，這種主鍵的數據應該和應用無關，組件的的方法是使用AUTO_INCREMENT自增列。這樣可以保證數據行是按照順序寫入，對於根據主鍵做關聯的操作性能也會更好。
最好避免隨機的（不連續，且值的分布范圍非常大的）聚簇索引，特別是對於io密集型的應用。例如，從性能的角度考慮，使用UUID來作為聚簇索引則會很糟糕：它使得聚簇索引的插入變得完全隨機，這是最壞的情況，使得數據沒有任何聚集特性。
因為主鍵的值時順序的，索引InnoDB 把每一條記錄都存儲在上一條記錄的后面。當達到頁的最大填充因子時（InnoDB 默認的最大填充因子是頁大小的15/16 ,留出部分空間用於以后修改），下一條記錄就會寫入到新的頁中。一旦數據按照這種順序的方式加載，主鍵頁就會近似於被順序的記錄填滿，這也正是所期望的結果（然而二級索引頁可能不一樣）。
使用UUID聚簇索引的表插入數據，因為新的行的主鍵值不一定比之前插入的大，所以InnoDB 無法簡單的總是把新行插入到索引的最后，而是需要為新的行尋找到合適的位置--通常是已有數據的中間位置--並且分配空間。這會增加很多的額外操作。並導致數據分布不夠優化。下面是總結的一些缺點：
寫入的目標頁可能已經數到磁盤上並從緩存中移除，或者是還沒有被加載到緩存中，InnoDB在插入之前不得不先找到並從磁盤讀取目標頁到內存中。這將導致大量的磁盤io。
因為寫入是亂序的，InnoDB 不得不頻繁的做分頁操作，以便為新的行分配空間。頁分裂會導致移動大量數據，一次插入最少需要修改三個頁面，而不是一個頁。
由於頻繁的頁分裂，頁會變得稀疏，並且被不規則的填充，所以最終數據會有碎片。
總結：使用InnoDB 時應該盡可能地按照主鍵順序插入數據，並且盡可能地使用單調增加的聚簇鍵的值來插入新行。