引言

回想四年前，我在學(xué)習(xí)mysql的索引這塊的時(shí)候，老師在講索引的時(shí)候，是像下面這么說(shuō)的

索引就像一本書(shū)的目錄。而當(dāng)用戶通過(guò)索引查找數(shù)據(jù)時(shí)，就好比用戶通過(guò)目錄查詢某章節(jié)的某個(gè)知識(shí)點(diǎn)。這樣就幫助用戶有效地提高了查找速度。所以，使用索引可以有效地提高數(shù)據(jù)庫(kù)系統(tǒng)的整體性能。

嗯，這么說(shuō)其實(shí)也對(duì)。但是呢，大家看完這種說(shuō)法，其實(shí)可能還是覺(jué)得太抽象了！因此呢，我還想再深入的細(xì)說(shuō)一下，所以就有了此文！

需要說(shuō)明的是，我說(shuō)的內(nèi)容只在Mysql的Innodb引擎中是成立的。在Sql Server、oracle、Mysql的Mysiam引擎中的正確性，不一定成立！

InnoDB是 MySQL最常用的存儲(chǔ)引擎，了解InnoDB存儲(chǔ)引擎的索引對(duì)于日常工作有很大的益處，索引的存在便是為了加速數(shù)據(jù)庫(kù)行記錄的檢索。

什么是索引？

索引(index)翻譯為一個(gè)目錄，用于快速定位我們想要找的數(shù)據(jù)的位置。例如：我們把一個(gè)數(shù)據(jù)庫(kù)比作一本書(shū)，而索引(index)就是書(shū)中的目錄，此刻要找到書(shū)的某個(gè)感興趣的內(nèi)容，我們一般是不會(huì)整本書(shū)翻完再去確認(rèn)該內(nèi)容在哪里，而是通過(guò)書(shū)的目錄，定位到該內(nèi)容章節(jié)所在頁(yè)數(shù)，最后直接翻到該頁(yè)面。

我們來(lái)看看在數(shù)據(jù)庫(kù)中的索引：

全表掃描 VS 索引掃描

以字典為例，全表掃描就是如果我們查找某個(gè)字時(shí)，那么通讀一遍新華字典，然后找到我們想要找到的字，而跟全表掃描相對(duì)應(yīng)的就是索引查找，索引查找就是在表的索引部分找到我們想要找的數(shù)據(jù)具體位置，然后會(huì)到表里面將我們想要找的數(shù)據(jù)全部查出。

OK，廢話不多說(shuō)，開(kāi)始啰嗦!

正文

索引的科普

先引進(jìn)聚簇索引和非聚簇索引的概念！

我們平時(shí)在使用的Mysql中，使用下述語(yǔ)句

CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [USING index_type] ON tbl_name (index_col_name,...) index_col_name: col_name [(length)] [ASC | DESC]

創(chuàng)建的索引，如復(fù)合索引、前綴索引、唯一索引，都是屬于非聚簇索引，在有的書(shū)籍中，又將其稱為輔助索引(secondary index)。在后文中，我們稱其為非聚簇索引，其數(shù)據(jù)結(jié)構(gòu)為B+樹(shù)。

那么，這個(gè)聚簇索引，在Mysql中是沒(méi)有語(yǔ)句來(lái)另外生成的。在Innodb中，Mysql中的數(shù)據(jù)是按照主鍵的順序來(lái)存放的。那么聚簇索引就是按照每張表的主鍵來(lái)構(gòu)造一顆B+樹(shù)，葉子節(jié)點(diǎn)存放的就是整張表的行數(shù)據(jù)。由于表里的數(shù)據(jù)只能按照一顆B+樹(shù)排序，因此一張表只能有一個(gè)聚簇索引。

在Innodb中，聚簇索引默認(rèn)就是主鍵索引。

這個(gè)時(shí)候，機(jī)智的讀者，應(yīng)該要問(wèn)我

如果我的表沒(méi)建主鍵呢？

回答是，如果沒(méi)有主鍵，則按照下列規(guī)則來(lái)建聚簇索引

沒(méi)有主鍵時(shí)，會(huì)用一個(gè)唯一且不為空的索引列做為主鍵，成為此表的聚簇索引如果沒(méi)有這樣的索引，InnoDB會(huì)隱式定義一個(gè)主鍵來(lái)作為聚簇索引。

ps:大家還記得，自增主鍵和uuid作為主鍵的區(qū)別么？由于主鍵使用了聚簇索引，如果主鍵是自增id，，那么對(duì)應(yīng)的數(shù)據(jù)一定也是相鄰地存放在磁盤(pán)上的，寫(xiě)入性能比較高。如果是uuid的形式，頻繁的插入會(huì)使innodb頻繁地移動(dòng)磁盤(pán)塊，寫(xiě)入性能就比較低了。

索引原理介紹

先來(lái)一張帶主鍵的表，如下所示，pId是主鍵

畫(huà)出該表的結(jié)構(gòu)圖如下

如上圖所示，分為上下兩個(gè)部分，上半部分是由主鍵形成的B+樹(shù)，下半部分就是磁盤(pán)上真實(shí)的數(shù)據(jù)！那么，當(dāng)我們， 執(zhí)行下面的語(yǔ)句

select * from table where pId='11'

那么，執(zhí)行過(guò)程如下

如上圖所示，從根開(kāi)始，經(jīng)過(guò)3次查找，就可以找到真實(shí)數(shù)據(jù)。如果不使用索引，那就要在磁盤(pán)上，進(jìn)行逐行掃描，直到找到數(shù)據(jù)位置。顯然，使用索引速度會(huì)快。但是在寫(xiě)入數(shù)據(jù)的時(shí)候，需要維護(hù)這顆B+樹(shù)的結(jié)構(gòu)，因此寫(xiě)入性能會(huì)下降！

OK，接下來(lái)引入非聚簇索引!我們執(zhí)行下面的語(yǔ)句

create index index_name on table(name);

此時(shí)結(jié)構(gòu)圖如下所示

大家注意看，會(huì)根據(jù)你的索引字段生成一顆新的B+樹(shù)。因此， 我們每加一個(gè)索引，就會(huì)增加表的體積， 占用磁盤(pán)存儲(chǔ)空間。然而，注意看葉子節(jié)點(diǎn)，非聚簇索引的葉子節(jié)點(diǎn)并不是真實(shí)數(shù)據(jù)，它的葉子節(jié)點(diǎn)依然是索引節(jié)點(diǎn)，存放的是該索引字段的值以及對(duì)應(yīng)的主鍵索引(聚簇索引)。

如果我們執(zhí)行下列語(yǔ)句

select * from table where name='lisi'

此時(shí)結(jié)構(gòu)圖如下所示

通過(guò)上圖紅線可以看出，先從非聚簇索引樹(shù)開(kāi)始查找，然后找到聚簇索引后。根據(jù)聚簇索引，在聚簇索引的B+樹(shù)上，找到完整的數(shù)據(jù)！

那

什么情況不去聚簇索引樹(shù)上查詢呢？

還記得我們的非聚簇索引樹(shù)上存著該索引字段的值么。如果，此時(shí)我們執(zhí)行下面的語(yǔ)句

select name from table where name='lisi'

此時(shí)結(jié)構(gòu)圖如下

如上圖紅線所示，如果在非聚簇索引樹(shù)上找到了想要的值，就不會(huì)去聚簇索引樹(shù)上查詢。還記得，博主在《select的正確姿勢(shì)》提到的索引問(wèn)題么：

當(dāng)執(zhí)行select col from table where col = ?，col上有索引的時(shí)候，效率比執(zhí)行select * from table where col = ? 速度快好幾倍！

看完上面的圖，你應(yīng)該對(duì)這句話有更深層的理解了。

那么這個(gè)時(shí)候，我們執(zhí)行了下述語(yǔ)句，又會(huì)發(fā)生什么呢？

create index index_birthday on table(birthday);

此時(shí)結(jié)構(gòu)圖如下

看到了么，多加一個(gè)索引，就會(huì)多生成一顆非聚簇索引樹(shù)。因此，很多文章才說(shuō)，索引不能亂加。因?yàn)椋袔讉€(gè)索引，就有幾顆非聚簇索引樹(shù)！你在做插入操作的時(shí)候，需要同時(shí)維護(hù)這幾顆樹(shù)的變化！因此，如果索引太多，插入性能就會(huì)下降!

總結(jié)

講到這里，大家應(yīng)該清楚的明白索引的原理了！可能細(xì)節(jié)方面還不夠嚴(yán)謹(jǐn)，但是我覺(jué)得一個(gè)研發(fā)，理解到這里可以了，夠用了，畢竟我們也不是專(zhuān)業(yè)的DBA。
希望大家有所收獲！