1. 程式人生 > >【原創】MySQL(Innodb)索引的原理

【原創】MySQL(Innodb)索引的原理

day 希望 默認 數據位 依然 htm 排序 src 整體

引言

回想四年前,我在學習mysql的索引這塊的時候,老師在講索引的時候,是像下面這麽說的

索引就像一本書的目錄。而當用戶通過索引查找數據時,就好比用戶通過目錄查詢某章節的某個知識點。這樣就幫助用戶有效地提高了查找速度。所以,使用索引可以有效地提高數據庫系統的整體性能。

嗯,這麽說其實也對。但是呢,大家看完這種說法,其實可能還是覺得太抽象了!因此呢,我還想再深入的細說一下,所以就有了此文!
需要說明的是,我說的內容只在Mysql的Innodb引擎中是成立的。在Sql Server、oracle、Mysql的Mysiam引擎中的正確性,不一定成立!
OK,廢話不多說,開始啰嗦!

正文

索引的科普

先引進聚簇索引和非聚簇索引的概念!
我們平時在使用的Mysql中,使用下述語句

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

創建的索引,如復合索引、前綴索引、唯一索引,都是屬於非聚簇索引,在有的書籍中,又將其稱為輔助索引(secondary index)。在後文中,我們稱其為非聚簇索引,其數據結構為B+樹。

那麽,這個聚簇索引,在Mysql中是沒有語句來另外生成的。在Innodb中,Mysql中的數據是按照主鍵的順序來存放的。那麽聚簇索引就是按照每張表的主鍵來構造一顆B+樹,葉子節點存放的就是整張表的行數據。由於表裏的數據只能按照一顆B+樹排序,因此一張表只能有一個聚簇索引。

在Innodb中,聚簇索引默認就是主鍵索引。
這個時候,機智的讀者,應該要問我

如果我的表沒建主鍵呢?

回答是,如果沒有主鍵,則按照下列規則來建聚簇索引

  • 沒有主鍵時,會用一個唯一且不為空的索引列做為主鍵,成為此表的聚簇索引
  • 如果沒有這樣的索引,InnoDB會隱式定義一個主鍵來作為聚簇索引。

ps:大家還記得,自增主鍵和uuid作為主鍵的區別麽?由於主鍵使用了聚簇索引,如果主鍵是自增id,,那麽對應的數據一定也是相鄰地存放在磁盤上的,寫入性能比較高。如果是uuid的形式,頻繁的插入會使innodb頻繁地移動磁盤塊,寫入性能就比較低了。

索引原理介紹

先來一張帶主鍵的表,如下所示,pId是主鍵

pId name birthday
5 zhangsan 2016-10-02
8 lisi 2015-10-04
11 wangwu 2016-09-02
13 zhaoliu 2015-10-07

畫出該表的結構圖如下
技術分享圖片

如上圖所示,分為上下兩個部分,上半部分是由主鍵形成的B+樹,下半部分就是磁盤上真實的數據!那麽,當我們, 執行下面的語句

select * from table where pId='11'

那麽,執行過程如下
技術分享圖片
如上圖所示,從根開始,經過3次查找,就可以找到真實數據。如果不使用索引,那就要在磁盤上,進行逐行掃描,直到找到數據位置。顯然,使用索引速度會快。但是在寫入數據的時候,需要維護這顆B+樹的結構,因此寫入性能會下降!
OK,接下來引入非聚簇索引!我們執行下面的語句

create index index_name on table(name);

此時結構圖如下所示
技術分享圖片
大家註意看,會根據你的索引字段生成一顆新的B+樹。因此, 我們每加一個索引,就會增加表的體積, 占用磁盤存儲空間。然而,註意看葉子節點,非聚簇索引的葉子節點並不是真實數據,它的葉子節點依然是索引節點,存放的是該索引字段的值以及對應的主鍵索引(聚簇索引)。
如果我們執行下列語句

select * from table where name='lisi'

此時結構圖如下所示
技術分享圖片
通過上圖紅線可以看出,先從非聚簇索引樹開始查找,然後找到聚簇索引後。根據聚簇索引,在聚簇索引的B+樹上,找到完整的數據!

什麽情況不去聚簇索引樹上查詢呢?

還記得我們的非聚簇索引樹上存著該索引字段的值麽。如果,此時我們執行下面的語句

select name from table where name='lisi'

此時結構圖如下
技術分享圖片
如上圖紅線所示,如果在非聚簇索引樹上找到了想要的值,就不會去聚簇索引樹上查詢。還記得,博主在《select的正確姿勢》提到的索引問題麽:

當執行select col from table where col = ?,col上有索引的時候,效率比執行select * from table where col = ? 速度快好幾倍!

看完上面的圖,你應該對這句話有更深層的理解了。

那麽這個時候,我們執行了下述語句,又會發生什麽呢?

create index index_birthday on table(birthday);

此時結構圖如下
技術分享圖片
看到了麽,多加一個索引,就會多生成一顆非聚簇索引樹。因此,很多文章才說,索引不能亂加。因為,有幾個索引,就有幾顆非聚簇索引樹!你在做插入操作的時候,需要同時維護這幾顆樹的變化!因此,如果索引太多,插入性能就會下降!

總結

講到這裏,大家應該清楚的明白索引的原理了!可能細節方面還不夠嚴謹,但是我覺得一個研發,理解到這裏可以了,夠用了,畢竟我們也不是專業的DBA。
希望大家有所收獲!

【原創】MySQL(Innodb)索引的原理