再聊 MySQL 聚簇索引
為什么是再次理解呢？因為松哥之前寫過相關的文章介紹過聚簇索引，但是感覺還不夠，因此今天想再來和小伙伴們聊一聊這個話題。
一. 什么是聚簇索引
數據庫的索引從不同的角度可以劃分成不同的類型，聚簇索引便是其中一種。
聚簇索引英文是 Clustered Index，有時候小伙伴們可能也會看到有人將之稱為聚集索引等，與之相對的是非聚簇索引或者二級索引。
聚簇索引并不是一種單獨的索引類型，而是一種數據的存儲方式。在 MySQL 的 InnoDB 存儲引擎中，所謂的聚簇索引實際上就是在同一個 B+Tree 中保存了索引和數據行：此時，數據放在葉子結點中，聚簇聚簇，意思就是說數據行和對應的鍵值緊湊的存在一起。
假設我有如下數據：
id(主鍵) | username | age | address | gender |
1 | ab | 99 | 深圳 | 男 |
2 | ac | 98 | 廣州 | 男 |
3 | af | 88 | 北京 | 女 |
4 | bc | 80 | 上海 | 女 |
5 | bg | 85 | 重慶 | 女 |
6 | bw | 95 | 天津 | 男 |
7 | bw | 99 | ?？?br> | 女 |
8 | cc | 92 | 武漢 | 男 |
9 | ck | 90 | 深圳 | 男 |
10 | cx | 93 | 深圳 | 男 |
那么它的聚簇索引大概就是這個樣子：
那么大家可以看到，葉子上既有主鍵值（索引）又有數據行，節點上則只有主鍵值（索引）。
小伙伴們想想，MySQL 表中的數據在磁盤中只可能保存一份，不可能保存兩份，所以，在一個表中，聚簇索引只可能有一個，不可能有多個。
二. 聚簇索引和主鍵
有的小伙伴搞不清楚這兩者之間的關系，甚至將兩者劃等號，這是一個巨大的誤區。
在有的數據庫中，支持開發者自由的選擇使用哪一個索引作為聚簇索引，但是 MySQL 中是不支持這個特性的。
在 MySQL 中，如果表本身就有設置主鍵，那么主鍵就是聚簇索引；如果表本身沒有設置主鍵，則會選擇表中的一個唯一且非空的索引來作為聚簇索引；如果表中連唯一非空的索引都沒有，那么就會自動選擇表中的隱式主鍵來作為聚簇索引。關于 MySQL 中表的隱式主鍵，松哥會在將來的文章中和大家介紹。
不過一般來說，還是建議大家自己來為表設置主鍵，因為隱式主鍵是自增的，自增的都會存在一個問題：在自增值上會存在非常高的鎖競爭問題，主鍵的上界會稱為熱點數據，因為所有的插入操作都要主鍵自增，又不能重復，所以會發生鎖競爭進而導致性能降低。
根據上面的介紹，我們可以總結出 MySQL 中聚簇索引和主鍵索引的關系如下：
- 聚簇索引不一定是主鍵索引。
- 主鍵索引一定是聚簇索引。
三. 聚簇索引優缺點
先來說優點：
- 相互關聯的數據我們可以將之保存在一起。例如有一個用戶訂單表，我們可以根據 用戶 ID + 訂單 ID 來聚集所有數據，用戶 ID 可能會重復，訂單 ID 則不會重復，這樣我們就能夠將一個用戶相關的訂單數據都保存在一起，如果需要查詢一個用戶的所有訂單，就會非?？欤恍枰倭康拇疟P IO 就可以做到。
- 不需要回表，因此數據訪問速度更快。在聚簇索引中，索引和數據都在同一棵 B+Tree 上，因此從聚簇索引中獲取到的數據比從非聚簇索引上獲取數據更快（非聚簇索引需要回表）。
- 對于第一點的案例，如果我們想根據用戶 ID 查詢到這個用戶所有的訂單 ID，那么此時都不用去到葉子結點了，因為支節點上就有我們需要的數據，所以直接利用覆蓋索引的特性，就可以讀取到需要的數據。
這些就是聚簇索引一些常見的優點，我們在日常的表設計中，其實應該充分利用好這些優點。
再來看看缺點：
- 小伙伴們發現，前面我們說的聚簇索引的優勢主要是聚簇索引減少了 IO 次數，從而提高了數據庫的性能，但是有的 IO 密集型應用，可能直接上一個足夠大的內存，把數據都讀取到內存中操作，此時聚簇索引就沒有啥優勢了。
- 隨機主鍵會導致頁分裂問題，主鍵順序插入的話，相對來說效率會高一些，因為在 B+Tree 中只需要不斷往后面追加即可；但是主鍵如果是非順序插入的話，效率就會低很多，因為可能會涉及到頁分裂問題。以上面那張圖為例，假設每個節點可以保存三條數據，現在我們要插入一個主鍵是 4.5 的記錄，那么就需要把主鍵為 5 的值往后移動，進而導致主鍵為 8 的節點也要往后移動。頁分裂會導致數據插入效率降低并且占用更多的存儲空間。
- 非聚簇索引（二級索引）查詢的時候需要回表。因為一個索引就是一棵索引樹，數據都在聚簇索引上，所以如果使用非聚簇索引進行搜索，非聚簇索引的葉子上存儲的是主鍵值，先找到主鍵值，然后拿著主鍵值再來聚簇索引上搜索，這樣一共就查詢了兩棵索引樹，這就是回表。
四. 最佳實踐
看了上面的介紹，相信小伙伴已經了解了，在使用聚簇索引的時候，主鍵最好不要使用 UUID 這種隨機字符串，使用 UUID 隨機字符串至少存在兩方面的問題：
- 插入效率低，因為插入可能會導致頁分裂，這個前面已經說過了。
- UUID 字符串所占用的存儲空間遠遠大于一個 bigint，如果使用 UUID 來做主鍵，意味著在二級索引中，一個葉子結點能夠存儲的主鍵值就非常有限，進而可能會導致樹增高，搜索時候 IO 次數增多，性能下降。
所以相對來說，主鍵自增會優于 UUID。那么主鍵自增就是最完美的方案了嗎？很多小伙伴可能也聽說過一句話：沒有銀彈！所以，主鍵自增其實也有問題，具體什么問題，我們下便文章繼續。
