詳解聚簇索引
一、聚族索引的構造
聚簇索引並不是一種單獨的索引類型，而是一種數據存儲方式。具體的細節依賴於其實現方式，但InnoDB的聚族索引實際上在同一個結構中保存了B-Tree索引和數據行。當表有聚族索引時，它的數據行存放在索引的葉子頁中。術語“聚族”表示數據行和相鄰的鍵值緊湊的存儲在一起。因爲無法同時把數據行放在兩個不同的地方，所以一個表只能有一個聚族索引。
因爲是存儲引擎負責實現索引，因此不是所有的存儲引擎都支持聚族索引。這裏我們主要關注InnoDB，但是這裏討論的原理對於任何支持聚族索引的存儲引擎都是適用的。
下面展示了聚族索引中的記錄是如何存放的。注意到，葉子頁包含了行的全部數據，但是節點頁只包含了索引列。
聚族主鍵可能對性能有幫助，但也可能導致嚴重的性能問題。所以需要仔細的考慮聚族索引，尤其是將表的引擎從InnoDB改成其他引擎的時候。
二、聚族索引的優點
- 可以把相關數據保存在一起。例如實現電子郵件時，可以根據用戶ID來聚集數據，這樣只需要從磁盤讀取少數的數據頁就能獲取某個用戶的全部郵件。如果沒有使用聚族索引，則每封郵件都可能導致一次磁盤I/O；
- 數據訪問更快。聚族索引將索引和數據保存在同一個B-Tree中，因此從聚族索引中獲取數據通常比在非聚族索引中查找更快。
- 使用覆蓋索引掃描的查詢可以直接使用節點中的主鍵值。
三、聚族索引的缺點
- 聚簇數據最大限度的提高了I/O密集型應用的性能，但如果數據全部都放在內存中，則訪問的順序就沒有那麼重要了，聚簇索引也就沒有那麼優勢了；
- 插入速度嚴重依賴於插入順序。按照主鍵的順序插入是加載數據到InnoDB表中速度最快的方式。但如果不是按照主鍵順序加載數據，那麼在加載完成後最好使用OPTIMIZE TABLE命令重新組織一下表。
- 更新聚簇索引列的代價很高，因爲會強制InnoDB將每個被更新的行移動到新的位置。
- 基於聚簇索引的表在插入新行，或者主鍵被更新導致需要移動行的時候，可能面臨“頁分裂”的問題。當行的主鍵值要求必須將這一行插入到某個已滿的頁中時，存儲引擎會將該頁分裂成兩個頁面來容納該行，這就是一次分裂操作。頁分裂會導致表佔用更多的磁盤空間。
- 聚簇索引可能導致全表掃描變慢，尤其是行比較稀疏，或者由於頁分裂導致數據存儲不連續的時候。
- 二級索引（非聚簇索引）可能比想象的要更大，因爲在二級索引的葉子節點包含了引用行的主鍵列。
- 二級索引訪問需要兩次索引查找，而不是一次。
備註： 有關二級索引需要兩次索引查找的問題？答案在於二級索引中保存的“行指針”的實質。要記住，二級索引葉子節點保存的不是指向行的物理位置的指針，而是行的主鍵值。這意味着通過二級索引查找行，存儲引擎需要找到二級索引的葉子節點獲得對應的主鍵值，然後根據這個值去聚簇索引中查找到對應的行。這裏做了重複的工作：兩次B-Tree查找而不是一次。對於InnoDB，自適應哈希索引能夠減少這樣的重複工作。
四、InnoDB和MyISAM的數據分佈對比
聚簇索引和非聚簇索引的數據分佈有區別，以及對應的主鍵索引和二級索引的數據分佈也有區別。
1、MyISAM的主鍵索引和二級索引
MyISAM的數據分佈非常簡單，MyISAM按照數據插入的順序存儲在磁盤上。在行的旁邊顯示了行號，從0開始遞增。因爲行是定長的，所以MyISAM可以從表的開頭跳過所需的字節找到需要的行。這種分佈方式很容易創建索引。並且，MyISAM中主鍵索引和其他索引在結構上沒有什麼不同。主鍵索引就是一個名爲primary的唯一非空索引。如下圖：
1、MyISAM數據行分佈
2、InnoDB的主鍵索引和二級索引
InnoDB的數據分佈，因爲InnoDB支持聚簇索引，索引使用非常不同的方式存儲這樣的數據，如下圖：
還有一點和MyISAM的不同是，InnoDB的二級索引和聚簇索引很不相同。InnoDB二級索引的葉子節點中存儲的不是“行指針”，而是主鍵值，並以此作爲指向行的“指針”。這樣的策略減少了當出現航移動或者數據頁分裂時二級索引的維護工作。使用主鍵值當作指針會讓二級索引佔用更多的空間，換來的好處是，InnoDB在移動行時無需更新二級索引中的這個“指針”。下圖就是InnoDB的二級索引：
如果正在使用InnoDB表並且沒有什麼數據需要聚集，那麼可以定義一個代理鍵作爲主鍵，這種主鍵的數據應該和應用無關，最簡單的方法是使用auto_increment自增列。這樣可以保證數據行是按照順序寫入，對於根據主鍵做關聯操作的性能也會更好。
最好避免隨機的聚簇索引，特別對於I/O密集型的應用。例如，從性能的角度考慮，使用UUID作爲聚簇索引會很糟糕：它使得聚簇索引的插入變得完全隨機，這是最壞的情況，使得數據沒有任何聚集特性。通過測試，向UUID主鍵插入行不僅花費的時間更長，而且索引佔用的空間也更大。這一方面是由於主鍵字段更長，另一方面毫無疑問是由於頁分裂和碎片導致的。
這是由於當主鍵的值是順序的，則InnoDB把每一條記錄都存儲在上一條記錄的後面。當達到頁的最大填充因子時（InnoDB默認的最大填充因子是頁大小的15/16，留出的部分空間用於以後修改），下一條記錄就會寫入新的頁中。一旦數據按照這樣順序的方式加載，主鍵頁就會近似於被順序的記錄填滿，這也是所期望的結果。
而當採用UUID的聚簇索引的表插入數據，因爲新行的主鍵值不一定比之前的插入值大，所以InnoDB無法簡單的總是把新行插入到索引的最後，而是需要爲新的行尋找合適的位置----通常是已有數據的中間位置----並且分配空間。這會增加很多額外的工作，並導致數據分佈不夠優化。下面是總結的一些缺點：
- 寫入目標頁可能已經刷到磁盤上並從緩存中移除，或者是還沒有被加載到緩存中，InnoDB在插入之前不得不先找到並從磁盤讀取目標頁到內存中，這將導致大量的隨機I/O；
- 因爲寫入是亂序的，InnoDB不得不頻繁的做頁分裂操作，以便爲新的行分配空間。頁分裂會導致移動大量數據，一次插入最少需要修改三個頁而不是一個頁。
- 由於頻繁的頁分裂，頁會變得稀疏並被不規則的填充，所以最終數據會有碎片。
- 把這些隨機值載入到聚簇索引以後，需要做一次optimize table來重建表並優化頁的填充。
注意：順序主鍵也有缺點：對於高併發工作負載，在InnoDB中按主鍵順序插入可能會造成明顯的爭用。主鍵的上界會成爲“熱點”。因爲所有的插入都發生在這裏，所以併發插入可能導致間隙鎖競爭。另一個熱點可能是auto_increment鎖機制；如果遇到這個問題，則可能需要考慮重新設計表或者應用，或者更改innodb_autonc_lock_mode配置