作者： 58沈劍 [架構師之路]
《數據庫索引阐斜，到底是什么做的箱蝠？》介紹了B+樹掰担，它是一種非常適合用來做數據庫索引的數據結構：
(1)很適合磁盤存儲汇陆，能夠充分利用局部性原理，磁盤預讀带饱；
(2)很低的樹高度毡代，能夠存儲大量數據；
(3)索引本身占用的內存很芯琅凇月趟；
(4)能夠很好的支持單點查詢，范圍查詢恢口，有序性查詢孝宗；
數據庫的索引分為主鍵索引（Primary Inkex）與普通索引（Secondary Index）。InnoDB和MyISAM是怎么利用B+樹來實現這兩類索引耕肩，其又有什么差異呢因妇？這是今天要聊的內容问潭。
一，MyISAM的索引
MyISAM的索引與行記錄是分開存儲的婚被，叫做非聚集索引（UnClustered Index）狡忙。
其主鍵索引與普通索引沒有本質差異：
有連續(xù)聚集的區(qū)域單獨存儲行記錄
主鍵索引的葉子節(jié)點，存儲主鍵址芯，與對應行記錄的指針
普通索引的葉子結點灾茁，存儲索引列，與對應行記錄的指針
畫外音：MyISAM的表可以沒有主鍵谷炸。
主鍵索引與普通索引是兩棵獨立的索引B+樹北专，通過索引列查找時，先定位到B+樹的葉子節(jié)點旬陡，再通過指針定位到行記錄拓颓。
舉個例子，MyISAM：
t(id PK, name KEY, sex, flag);
表中有四條記錄：
1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B
其B+樹索引構造如上圖：
行記錄單獨存儲
id為PK描孟，有一棵id的索引樹驶睦，葉子指向行記錄
name為KEY，有一棵name的索引樹匿醒，葉子也指向行記錄
二场航、InnoDB的索引
InnoDB的主鍵索引與行記錄是存儲在一起的，故叫做聚集索引（Clustered Index）：
沒有單獨區(qū)域存儲行記錄
主鍵索引的葉子節(jié)點廉羔，存儲主鍵旗闽，與對應行記錄（而不是指針）
畫外音：因此，InnoDB的PK查詢是非趁哿恚快的。
因為這個特性嫡意，InnoDB的表必須要有聚集索引：
(1)如果表定義了PK举瑰，則PK就是聚集索引；
(2)如果表沒有定義PK蔬螟，則第一個非空unique列是聚集索引此迅；
(3)否則，InnoDB會創(chuàng)建一個隱藏的row-id作為聚集索引旧巾；
聚集索引耸序，也只能夠有一個，因為數據行在物理磁盤上只能有一份聚集存儲鲁猩。
InnoDB的普通索引可以有多個坎怪，它與聚集索引是不同的：
- 普通索引的葉子節(jié)點，存儲主鍵（也不是指針）
對于InnoDB表廓握，這里的啟示是：
(1)不建議使用較長的列做主鍵搅窿，例如char(64)嘁酿，因為所有的普通索引都會存儲主鍵，會導致普通索引過于龐大男应；
(2)建議使用趨勢遞增的key做主鍵闹司，由于數據行與索引一體，這樣不至于插入記錄時沐飘，有大量索引分裂游桩，行記錄移動；
仍是上面的例子耐朴，只是存儲引擎換成InnoDB：
t(id PK, name KEY, sex, flag);
表中還是四條記錄：
1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B
其B+樹索引構造如上圖：
id為PK借卧，行記錄和id索引樹存儲在一起
name為KEY，有一棵name的索引樹隔箍，葉子存儲id
當：
select * from t where name=‘lisi’;
會先通過name輔助索引定位到B+樹的葉子節(jié)點得到id=5谓娃，再通過聚集索引定位到行記錄。
畫外音：所以蜒滩，其實掃了2遍索引樹滨达。
三，總結
MyISAM和InnoDB都使用B+樹來實現索引：
MyISAM的索引與數據分開存儲
MyISAM的索引葉子存儲指針俯艰，主鍵索引與普通索引無太大區(qū)別
InnoDB的聚集索引和數據行統(tǒng)一存儲
InnoDB的聚集索引存儲數據行本身捡遍，普通索引存儲主鍵
InnoDB一定有且只有一個聚集索引
InnoDB建議使用趨勢遞增整數作為PK，而不宜使用較長的列作為PK
架構師之路-分享可落地的架構文章
相關推薦：
《數據庫索引竹握，到底是什么做的画株？》強烈推薦
