大家可能都聽過數(shù)據(jù)庫索引，當(dāng)然作為開發(fā)者來說其實大部分時間也用過索引。但是可能有的人知道索引是干什么的，但是對于索引的結(jié)構(gòu)卻不是很了解。所以這篇博客我會談?wù)剬λ饕Y(jié)構(gòu)的一些知識以及分享如何從零開始一層一層向上最終理解索引結(jié)構(gòu)。

我們從一個簡單的表開始，建表語句如下：

CREATE TABLE `user` (`id` INT NOT NULL,`age` INT NULL,`height` INT NULL,`weight` INT NULL,`name` VARCHAR(45) NULL,PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8mb4;

這是一條簡單的SQL，相信大家都可以理解，接下里我們往數(shù)據(jù)庫表中插入幾條數(shù)據(jù)：

INSERT INTO user(id,age,height,weight,name)VALUES(2,1,2,7,'小吉'); INSERT INTO user(id,age,height,weight,name)VALUES(5,2,1,8,'小尼'); INSERT INTO user(id,age,height,weight,name)VALUES(1,4,3,1,'小泰'); INSERT INTO user(id,age,height,weight,name)VALUES(4,1,5,2,'小美'); INSERT INTO user(id,age,height,weight,name)VALUES(3,5,6,7,'小蔡');

然后查找一下數(shù)據(jù)庫中是否已經(jīng)插入成功了：

可以看到，數(shù)據(jù)已經(jīng)完整地放到了我們創(chuàng)建的user表中。但是不知道大家發(fā)現(xiàn)了什么沒有，好像發(fā)生了一件非常詭異的事情，我們插入的數(shù)據(jù)好像亂序了，MySQL好像悄悄的給我們按照id排了個序。為什么會出現(xiàn)MySQL在我們沒有顯式排序的情況下，默默幫我們排了序呢？它是在什么時候進行排序的？

頁的引入

頁的概念

在操作系統(tǒng)的概念中，當(dāng)我們往磁盤中取數(shù)據(jù)，假設(shè)要取出的數(shù)據(jù)的大小是1KB，但是操作系統(tǒng)并不會只取出這1kb的數(shù)據(jù)，而是會取出4KB的數(shù)據(jù)，因為操作系統(tǒng)的一個頁表項的大小是4KB。那為什么我們只需要1KB的數(shù)據(jù)，但是操作系統(tǒng)要取出4KB的數(shù)據(jù)呢？這就涉及到一個程序局部性的概念，“一個程序在訪問了一條數(shù)據(jù)之后，在之后會有極大的可能再次訪問這條數(shù)據(jù)和訪問這條數(shù)據(jù)的相鄰數(shù)據(jù)”，所以索性直接加載4KB的數(shù)據(jù)到內(nèi)存中，下次要訪問這一頁的數(shù)據(jù)時，直接從內(nèi)存中找，可以減少磁盤IO次數(shù)，我們知道，磁盤IO是影響程序性能主要的因素，因為磁盤IO和內(nèi)存IO的速度是不可同日而語的。

或許看完上面那一大段描述，還是有些抽象，所以我們索性回到數(shù)據(jù)庫層面中，重新理解頁的概念。拋開所有東西不談，假設(shè)還是我們剛才插入的那些數(shù)據(jù)，我們現(xiàn)在要找id = 5的數(shù)據(jù)，依照最原始的方式，我們一定會想到的就是——遍歷，沒錯，這也是我們剛開始學(xué)計算機的時候最常用的尋找數(shù)據(jù)的方式。那么我們就來看看，以遍歷的方式，我們找到id=5的數(shù)據(jù)，需要經(jīng)歷幾次磁盤IO：

首先，我們得先從id=1的數(shù)據(jù)開始讀起，然后判斷是否是我們需要的數(shù)據(jù)；

如果不是，就再取id=2的數(shù)據(jù)，再進行判斷，循環(huán)往復(fù)；

毋庸置疑，在MySQL幫我們排好序之后，我們需要經(jīng)歷五次磁盤IO，才能將5號數(shù)據(jù)找到并讀出來。

在引入頁的概念之后，MySQL會將多條數(shù)據(jù)存在一個叫“頁”的數(shù)據(jù)結(jié)構(gòu)中，當(dāng)MySQL讀取id=1的數(shù)據(jù)時，會將id=1數(shù)據(jù)所在的頁整頁讀到內(nèi)存中，然后在內(nèi)存中進行遍歷判斷，由于內(nèi)存的IO速度比磁盤高很多，所以相對于磁盤IO，幾乎可以忽略不計，那么我們來看看這樣讀取數(shù)據(jù)我們需要經(jīng)歷幾次磁盤IO（假設(shè)每一頁可以存4條數(shù)據(jù)）：

我們第一次會讀取id=1的數(shù)據(jù)，并且將id=1到id=4的數(shù)據(jù)全部讀到內(nèi)存中，這是第一次磁盤IO；

第二次將讀取id=5的數(shù)據(jù)到內(nèi)存中，這是第二次磁盤IO；

所以我們只需要經(jīng)歷2次磁盤IO就可以找到id=5的這條數(shù)據(jù)。

但其實，在MySQL的InnoDb引擎中，頁的大小是16KB，是操作系統(tǒng)的4倍，而int類型的數(shù)據(jù)是4個字節(jié)，其它類型的數(shù)據(jù)的字節(jié)數(shù)通常也在4000字節(jié)以內(nèi)，所以一頁是可以存放很多很多條數(shù)據(jù)的，而MySQL的數(shù)據(jù)正是以頁為基本單位組合而成的。

上圖就是我們目前為止所理解的頁的結(jié)構(gòu)，他包含我們的多條數(shù)據(jù)，另外，MySQL的數(shù)據(jù)以頁組成，那么它有指向下一頁的指針和指向上一頁的指針。那么說到這里，其實可以回答第一個問題了，MySQL實際上就是在我們插入數(shù)據(jù)的時候，就幫我們在頁中排好了序，至于為什么要排序，這里先賣個關(guān)子，接著往下看。
上文中我們提了一個問題，為什么數(shù)據(jù)庫在插入數(shù)據(jù)時要對其進行排序呢？我們按正常順序插入數(shù)據(jù)不是也挺好的嗎？這就要涉及到一個數(shù)據(jù)庫查詢流程的問題了，無論如何，我們是絕對不會去平白無故地在插入數(shù)據(jù)時增加一個操作來讓流程復(fù)雜化的，所以插入數(shù)據(jù)時排序一定有其目的，就是優(yōu)化查詢的效率。而我們不難看出，頁內(nèi)部存放數(shù)據(jù)的模塊，實質(zhì)上就是一個鏈表的結(jié)構(gòu)，鏈表的特點也就是增刪快，查詢慢，所以優(yōu)化查詢的效率是必須的。

基于單頁模式存儲的查詢流程

還是基于我們第一節(jié)中的那張頁圖來談，我們插入了五條數(shù)據(jù)，id分別是從1-5，那么假設(shè)我要找一個表中不存在的id，假設(shè)id=-1，那么現(xiàn)在的查詢流程就是：

將id=1的這一整頁數(shù)據(jù)取出，進行逐個比對;

當(dāng)我們找到id=1的這條數(shù)據(jù)時，發(fā)現(xiàn)這個id大于我們所需要找的哪個id，由于數(shù)據(jù)庫在插入數(shù)據(jù)時，已經(jīng)進行過排序了，那么在id=1的數(shù)據(jù)后面，都是id>1的數(shù)據(jù)，所以我們就不需要再繼續(xù)往下尋找了。

如果在插入時沒有進行排序，那毋庸置疑，我們需要再繼續(xù)往下進行尋找，逐條查找直到到結(jié)尾也沒有找到這條數(shù)據(jù)，才能返回不存在這條數(shù)據(jù)。但是基于單頁模式存儲的查詢可能帶來一定的問題，在現(xiàn)階段我們了解的頁模式中，只有一個功能，就是在查詢某條數(shù)據(jù)的時候直接將一整頁的數(shù)據(jù)加載到內(nèi)存中，以減少硬盤IO次數(shù)，從而提高性能。但是，我們也可以看到，現(xiàn)在的頁模式內(nèi)部，實際上是采用了鏈表的結(jié)構(gòu)，前一條數(shù)據(jù)指向后一條數(shù)據(jù)，本質(zhì)上還是通過數(shù)據(jù)的逐條比較來取出特定的數(shù)據(jù)。那么假設(shè)，我們這一頁中有一百萬條數(shù)據(jù)，我們要查的數(shù)據(jù)正好在最后一個，那么我們是不是一定要從前往后找到這一條數(shù)據(jù)呢？如果是這樣，我們需要查找的次數(shù)就達(dá)到了一百萬次，即使是在內(nèi)存中查找，這個效率也是不高的。那么有什么辦法來優(yōu)化這種情況下的查找效率呢？

頁目錄的引入

頁目錄概念

我們可以打個比方，我們在看書的時候，如果要找到某一節(jié)，而這一節(jié)我們并不知道在哪一頁，我們是不是就要從前往后，一節(jié)一節(jié)地去尋找我們需要的內(nèi)容的頁碼呢？答案是否定的，因為在書的前面，存在目錄，它會告訴你這一節(jié)在哪一頁，例如，第一節(jié)在第1頁、第二節(jié)在第13頁。在數(shù)據(jù)庫的頁中，實際上也使用了這種目錄的結(jié)構(gòu)，這就是頁目錄。引入頁目錄之后，我們所理解的頁結(jié)構(gòu)，就變成了這樣：

分析一下這張圖，實際上頁目錄就像是我們在看書的時候書本的目錄一樣，目錄項1就相當(dāng)于第一節(jié)，目錄項2就相當(dāng)于第二節(jié)，而每一條數(shù)據(jù)就相當(dāng)于書本的每一頁，這張圖就可以解釋成，第一節(jié)從第一頁開始，第二節(jié)從第三頁開始，而實際上，每個目錄項會存放自己這個目錄項當(dāng)中最小的id，也就是說，目錄項1中會存放1，而目錄項2會存放3。對比一下數(shù)據(jù)庫在沒有頁目錄時候的查找流程：

• 假設(shè)要查找id=3的數(shù)據(jù)，在沒有頁目錄的情況下，需要查找id=1、id=2、id=3，三次才能找到該數(shù)據(jù)；
• 有頁目錄之后，只需要先查看一下id=3存在于哪個目錄項下，然后直接通過目錄項進行數(shù)據(jù)的查找即可，如果在該目錄項下沒有找到這條數(shù)據(jù)，那么就可以直接確定這條數(shù)據(jù)不存在，這樣就大大提升了數(shù)據(jù)庫的查找效率，但是這種頁目錄的實現(xiàn)，首先就需要基于數(shù)據(jù)是在已經(jīng)進行過排序的的場景下，才可以發(fā)揮其作用。

所以看到這里，大家應(yīng)該明白第二個問題了，為什么數(shù)據(jù)庫在插入時會進行排序，這才是真正發(fā)揮排序的作用的地方。

頁的擴展

在上文中，我們基本上說明白了MySQL數(shù)據(jù)庫中頁的概念，以及它是如何基于頁來減少磁盤IO次數(shù)的，以及排序是如何優(yōu)化查詢的效率的。那么我們現(xiàn)在再來思考第三個問題：在開頭說頁的概念的時候，我們有說過，MySQL中每一頁的大小只有16KB，不會隨著數(shù)據(jù)的插入而自動擴容，所以這16KB不可能存下我們所有的數(shù)據(jù)，那么必定會有多個頁來存儲數(shù)據(jù)，那么在多頁的情況下，MySQL中又是怎么組織這些頁的呢？
針對這個問題，我們繼續(xù)來畫出我們現(xiàn)在所了解的多頁的結(jié)構(gòu)圖：

可以看到，在數(shù)據(jù)不斷變多的情況下，MySQL會再去開辟新的頁來存放新的數(shù)據(jù)，而每個頁都有指向下一頁的指針和指向上一頁的指針，將所有頁組織起來（這里修改了一下數(shù)據(jù)，將每一列的數(shù)據(jù)都放到了數(shù)據(jù)區(qū)中，其中第一個空格之前的代表id），第一頁中存放id為1-5的數(shù)據(jù)，第二頁存放id為6-10的數(shù)據(jù)，第三頁存放id為11-15的數(shù)據(jù)，需要注意的是在開辟新頁的時候，我們插入的數(shù)據(jù)不一定是放在新開辟的頁上，而是要進行所有頁的數(shù)據(jù)比較，來決定這條插入的數(shù)據(jù)放在哪一頁上，而完成數(shù)據(jù)插入之后，最終的多頁結(jié)構(gòu)就會像上圖中畫的那樣。

多頁模式

多頁模式概述

在多頁模式下，MySQL終于可以完成多數(shù)據(jù)的存儲了，就是采用開辟新頁的方式，將多條數(shù)據(jù)放在不同的頁中，然后同樣采用鏈表的數(shù)據(jù)結(jié)構(gòu)，將每一頁連接起來。那么可以思考第四個問題：多頁情況下是否對查詢效率有影響呢？針對這個問題，既然問出來了，那么答案是肯定的，多頁會對查詢效率產(chǎn)生一定的影響，影響主要就體現(xiàn)在，多頁其本質(zhì)也是一個鏈表結(jié)構(gòu)，只要是鏈表結(jié)構(gòu)，查詢效率一定不會高。假設(shè)數(shù)據(jù)又非常多條，數(shù)據(jù)庫就會開辟非常多的新頁，而這些新頁就會像鏈表一樣連接在一起，當(dāng)我們要在這么多頁中查詢某條數(shù)據(jù)時，它還是會從頭節(jié)點遍歷到存在我們要查找的那條數(shù)據(jù)所存在的頁上，我們好不容易通過頁目錄優(yōu)化了頁中數(shù)據(jù)的查詢效率，現(xiàn)在又出現(xiàn)了以頁為單位的鏈表，這不是前功盡棄了嗎？

優(yōu)化多頁模式

由于多頁模式會影響查詢的效率，那么肯定需要有一種方式來優(yōu)化多頁模式下的查詢。相信有同學(xué)已經(jīng)猜出來了，既然我們可以用頁目錄來優(yōu)化頁內(nèi)的數(shù)據(jù)區(qū)，那么我們也可以采取類似的方式來優(yōu)化這種多頁的情況。是的，頁內(nèi)數(shù)據(jù)區(qū)和多頁模式本質(zhì)上都是鏈表，那么的確可以采用相同的方式來對其進行優(yōu)化，它就是目錄頁。
我們對比頁內(nèi)數(shù)據(jù)區(qū)，來分析如何優(yōu)化多頁結(jié)構(gòu)。在單頁時，我們采用了頁目錄的目錄項來指向一行數(shù)據(jù)，這條數(shù)據(jù)就是存在于這個目錄項中的最小數(shù)據(jù)，那么就可以通過頁目錄來查找所需數(shù)據(jù)。所以對于多頁結(jié)構(gòu)也可以采用這種方式，使用一個目錄項來指向某一頁，而這個目錄項存放的就是這一頁中存放的最小數(shù)據(jù)的索引值。和頁目錄不同的地方在于，這種目錄管理的級別是頁，而頁目錄管理的級別是行。分析到這里，我們多頁模式的結(jié)構(gòu)就會是下圖所示的這樣：

存在一個目錄頁來管理頁目錄，目錄頁中的數(shù)據(jù)存放的就是指向的那一頁中最小的數(shù)據(jù)。這里要注意的一點是：其實目錄頁的本質(zhì)也是頁，普通頁中存的數(shù)據(jù)是項目數(shù)據(jù)，而目錄頁中存的數(shù)據(jù)是普通頁的地址。
假設(shè)我們要查找id=19的數(shù)據(jù)，那么按照以前的查找方式，我們需要從第一頁開始查找，發(fā)現(xiàn)不存在那么再到第二頁查找，一直找到第四頁才能找到id=19的數(shù)據(jù)，但是如果有了目錄頁，就可以使用id=19與目錄頁中存放的數(shù)據(jù)進行比較，發(fā)現(xiàn)19大于任何一條數(shù)據(jù)，于是進入id=16指向的頁進行查找，直接然后再通過頁內(nèi)的頁目錄行級別的數(shù)據(jù)的查找，很快就可以找到id為19的數(shù)據(jù)了。隨著數(shù)據(jù)越來越多，這種結(jié)構(gòu)的效率相對于普通的多頁模式，優(yōu)勢也就越來越明顯。
相信有對MySQL比較了解的同學(xué)已經(jīng)發(fā)現(xiàn)了，我們畫的最終的這幅圖，就是MySQL中的一種索引結(jié)構(gòu)——B+樹。

頁的完整結(jié)構(gòu)

說完了頁的概念和頁是如何一步一步地組合稱為B+樹的結(jié)構(gòu)之后，相信大家對于頁都有了一個比較清楚的認(rèn)知，所以這里就要開始說說官方概念了，基于我們上文所說的，給出一個完整的頁結(jié)構(gòu)，也算是對上文中自己理解頁結(jié)構(gòu)的一種補充。下圖為 Page 數(shù)據(jù)結(jié)構(gòu)：

• File Header 字段用于記錄 Page 的頭信息，其中比較重要的是 FIL_PAGE_PREV 和 FIL_PAGE_NEXT 字段，通過這兩個字段，我們可以找到該頁的上一頁和下一頁，實際上所有頁通過兩個字段可以形成一條雙向鏈表。
• Page Header 字段用于記錄 Page 的狀態(tài)信息。接下來的 Infimum 和 Supremum 是兩個偽行記錄，- Infimum（下確界）記錄比該頁中任何主鍵值都要小的值，Supremum （上確界）記錄比該頁中任何主鍵值都要大的值，這個偽記錄分別構(gòu)成了頁中記錄的邊界。
• User Records 中存放的是實際的數(shù)據(jù)行記錄，具體的行記錄結(jié)構(gòu)將在本文的第二節(jié)中詳細(xì)介紹。Free Space 中存放的是空閑空間，被刪除的行記錄會被記錄成空閑空間。Page Directory 記錄著與二叉查找相關(guān)的信息。File Trailer 存儲用于檢測數(shù)據(jù)完整性的校驗和等數(shù)據(jù)。

本篇文章著重聊了一下關(guān)于MySQL的索引結(jié)構(gòu)，從零開始慢慢構(gòu)建了一個B+樹索引，希望對大家理解索引有所幫助。

猜你感興趣：
MYSQL專題-絕對實用的MYSQL優(yōu)化總結(jié)
MYSQL專題-MySQL事務(wù)實現(xiàn)原理
MYSQL專題-MVCC多版本并發(fā)控制
MYSQL專題-MySQL三大日志binlog、redo log和undo log

更多文章請點擊：更多…

參考文章：
https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247490706&idx=1&sn=d98cd10845923c2bf5d933a8fd963cb5&chksm=ebd623bedca1aaa87256f9729192d024897ba70bc38a0abc314cd59b1a1349c52ec33f1074a1&scene=21#wechat_redirect
https://www.cnblogs.com/bdsir/p/8745553.html

總結(jié)

以上是生活随笔為你收集整理的MYSQL专题-由简到繁理解索引结构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。