pId | name | birthday |
---|---|---|
5 | zhangsan | 2016-10-02 |
8 | lisi | 2015-10-04 |
11 | wangwu | 2016-09-02 |
13 | zhaoliu | 2015-10-07 |
畫出該表的結(jié)構(gòu)圖如下
如上圖所示,分為上下兩個(gè)部分,上半部分是由主鍵形成的B+樹,下半部分就是磁盤上真實(shí)的數(shù)據(jù)!那么,當(dāng)我們, 執(zhí)行下面的語句
select * from table where pId='11'
那么,執(zhí)行過程如下
如上圖所示,從根開始,經(jīng)過3次查找,就可以找到真實(shí)數(shù)據(jù)。如果不使用索引,那就要在磁盤上,進(jìn)行逐行掃描,直到找到數(shù)據(jù)位置。顯然,使用索引速度會快。但是在寫入數(shù)據(jù)的時(shí)候,需要維護(hù)這顆B+樹的結(jié)構(gòu),因此寫入性能會下降!
OK,接下來引入非聚簇索引!我們執(zhí)行下面的語句
create index index_name on table(name);
此時(shí)結(jié)構(gòu)圖如下所示
大家注意看,會根據(jù)你的索引字段生成一顆新的B+樹。因此, 我們每加一個(gè)索引,就會增加表的體積, 占用磁盤存儲空間。然而,注意看葉子節(jié)點(diǎn),非聚簇索引的葉子節(jié)點(diǎn)并不是真實(shí)數(shù)據(jù),它的葉子節(jié)點(diǎn)依然是索引節(jié)點(diǎn),存放的是該索引字段的值以及對應(yīng)的主鍵索引(聚簇索引)。
如果我們執(zhí)行下列語句
select * from table where name='lisi'
此時(shí)結(jié)構(gòu)圖如下所示
通過上圖紅線可以看出,先從非聚簇索引樹開始查找,然后找到聚簇索引后。根據(jù)聚簇索引,在聚簇索引的B+樹上,找到完整的數(shù)據(jù)!
那
什么情況不去聚簇索引樹上查詢呢?
還記得我們的非聚簇索引樹上存著該索引字段的值么。如果,此時(shí)我們執(zhí)行下面的語句
select name from table where name='lisi'
此時(shí)結(jié)構(gòu)圖如下
如上圖紅線所示,如果在非聚簇索引樹上找到了想要的值,就不會去聚簇索引樹上查詢。還記得,博主在《select的正確姿勢》提到的索引問題么:
當(dāng)執(zhí)行select col from table where col = ?,col上有索引的時(shí)候,效率比執(zhí)行select * from table where col = ? 速度快好幾倍!
看完上面的圖,你應(yīng)該對這句話有更深層的理解了。
那么這個(gè)時(shí)候,我們執(zhí)行了下述語句,又會發(fā)生什么呢?
create index index_birthday on table(birthday);
此時(shí)結(jié)構(gòu)圖如下
看到了么,多加一個(gè)索引,就會多生成一顆非聚簇索引樹。因此,很多文章才說,索引不能亂加。因?yàn)?,有幾個(gè)索引,就有幾顆非聚簇索引樹!你在做插入操作的時(shí)候,需要同時(shí)維護(hù)這幾顆樹的變化!因此,如果索引太多,插入性能就會下降!
總結(jié)
講到這里,大家應(yīng)該清楚的明白索引的原理了!可能細(xì)節(jié)方面還不夠嚴(yán)謹(jǐn),但是我覺得一個(gè)研發(fā),理解到這里可以了,夠用了,畢竟我們也不是專業(yè)的DBA。
希望大家有所收獲!
標(biāo)簽:佛山 賀州 蘭州 南充 黃山 黔南 宿遷 馬鞍山
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《深入講解MySQL Innodb索引的原理》,本文關(guān)鍵詞 深入,講解,MySQL,Innodb,索引,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。