索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！-有解無憂

前言

Hello我又來了，快年底了，作為一個有抱負的碼農，我想給自己攢一個年終總結，自上上篇寫了手動搭建Redis集群和MySQL主從同步(非Docker)和上篇寫了動手實作MySQL讀寫分離and故障轉移之后，索性這次把資料庫中最核心的也是最難搞懂的內容，也就是索引，分享給大家，

這篇博客我會談談對于索引結構我自己的看法，以及分享如何從零開始一層一層向上最終理解索引結構，

從一個簡單的表開始

create table user(
    id int primary key,
    age int,
    height int,
    weight int,
    name varchar(32)
)engine = innoDb;

相信只要入門資料庫的同學都可以理解這個陳述句，我們也將從這個最簡單的表開始，一步步地理解MySQL的索引結構，

首先，我們往這個表中插入一些資料，

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,'小蔡');

我們來查一下，看看這些資料是否已經放入表中，

select * from user;

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

可以看到，資料已經完整地放到了我們創建的user表中，

但是不知道大家發現了什么沒有，好像發生了一件非常詭異的事情，我們插入的資料好像亂序了…

MySQL好像悄悄的給我們按照id排了個序，

為什么會出現MySQL在我們沒有顯式排序的情況下，默默幫我們排了序呢？它是在什么時候進行排序的？

頁的引入

不知道大家畢業多長時間了，作為一個剛學完作業系統不久的學渣，頁的概念依舊在腦中還沒有變涼，其實MySQL中也有類似頁的邏輯存盤單位，聽我慢慢道來，

在作業系統的概念中，當我們往磁盤中取資料，假設要取出的資料的大小是1KB，但是作業系統并不會只取出這1kb的資料，而是會取出4KB的資料，因為作業系統的一個頁表項的大小是4KB，那為什么我們只需要1KB的資料，但是作業系統要取出4KB的資料呢？

這就涉及到一個程式區域性的概念，具體的概念我背不清了，大概就是“一個程式在訪問了一條資料之后，在之后會有極大的可能再次訪問這條資料和訪問這條資料的相鄰資料”，所以索性直接加載4KB的資料到記憶體中，下次要訪問這一頁的資料時，直接從記憶體中找，可以減少磁盤IO次數，我們知道，磁盤IO是影響程式性能主要的因素，因為磁盤IO和記憶體IO的速度是不可同日而語的，

或許看完上面那一大段描述，還是有些抽象，所以我們索性回到資料庫層面中，重新理解頁的概念，

拋開所有東西不談，假設還是我們剛才插入的那些資料，我們現在要找id = 5的資料，依照最原始的方式，我們一定會想到的就是——遍歷，沒錯，這也是我們剛開始學計算機的時候最常用的尋找資料的方式，那么我們就來看看，以遍歷的方式，我們找到id=5的資料，需要經歷幾次磁盤IO，

首先，我們得先從id=1的資料開始讀起，然后判斷是否是我們需要的資料，如果不是，就再取id=2的資料，再進行判斷，回圈往復，毋庸置疑，在MySQL幫我們排好序之后，我們需要經歷五次磁盤IO，才能將5號資料找到并讀出來，

那么我們再來看看引入頁的概念之后，我們是如何讀資料的，

在引入頁的概念之后，MySQL會將多條資料存在一個叫“頁”的資料結構中，當MySQL讀取id=1的資料時，會將id=1資料所在的頁整頁讀到記憶體中，然后在記憶體中進行遍歷判斷，由于記憶體的IO速度比磁盤高很多，所以相對于磁盤IO，幾乎可以忽略不計，那么我們來看看這樣讀取資料我們需要經歷幾次磁盤IO（假設每一頁可以存4條資料），

那么我們第一次會讀取id=1的資料，并且將id=1到id=4的資料全部讀到記憶體中，這是第一次磁盤IO，第二次將讀取id=5的資料到記憶體中，這是第二次磁盤IO，所以我們只需要經歷2次磁盤IO就可以找到id=5的這條資料，

但其實，在MySQL的InnoDb引擎中，頁的大小是16KB，是作業系統的4倍，而int型別的資料是4個位元組，其它型別的資料的位元組數通常也在4000位元組以內，所以一頁是可以存放很多很多條資料的，而MySQL的資料正是以頁為基本單位組合而成的，

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

上圖就是我們目前為止所理解的頁的結構，他包含我們的多條資料，另外，MySQL的資料以頁組成，那么它有指向下一頁的指標和指向上一頁的指標，

那么說到這里，其實可以回答第一個問題了，MySQL實際上就是在我們插入資料的時候，就幫我們在頁中排好了序，至于為什么要排序，這里先賣個關子，接著往下看，

排序對性能的影響

上文中我們提了一個問題，為什么資料庫在插入資料時要對其進行排序呢？我們按正常順序插入資料不是也挺好的嗎？

這就要涉及到一個資料庫查詢流程的問題了，無論如何，我們是絕對不會去平白無故地在插入資料時增加一個操作來讓流程復雜化的，所以插入資料時排序一定有其目的，就是優化查詢的效率，

而我們不難看出，頁內部存放資料的模塊，實質上就是一個鏈表的結構，鏈表的特點也就是增刪快，查詢慢，所以優化查詢的效率是必須的，

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

還是基于我們第一節中的那張頁圖來談，我們插入了五條資料，id分別是從1-5，那么假設我要找一個表中不存在的id，假設id=-1，那么現在的查詢流程就是：

將id=1的這一整頁資料取出，進行逐個比對，那么當我們找到id=1的這條資料時，發現這個id大于我們所需要找的哪個id，由于資料庫在插入資料時，已經進行過排序了，那么在id=1的資料后面，都是id>1的資料，所以我們就不需要再繼續往下尋找了，

如果在插入時沒有進行排序，那毋庸置疑，我們需要再繼續往下進行尋找，逐條查找直到到結尾也沒有找到這條資料，才能回傳不存在這條資料，

當然，這只是排序優化的冰山一角，接著往下看，

上述頁模式可能帶來的問題

說完了排序，下面就來分析一下我們在第一節中的那幅圖，對于大資料量下有什么弊端，或者換一個說法，我們可以怎么對這個模式進行優化，

我們不難看出，在現階段我們了解的頁模式中，只有一個功能，就是在查詢某條資料的時候直接將一整頁的資料加載到記憶體中，以減少硬碟IO次數，從而提高性能，但是，我們也可以看到，現在的頁模式內部，實際上是采用了鏈表的結構，前一條資料指向后一條資料，本質上還是通過資料的逐條比較來取出特定的資料，

那么假設，我們這一頁中有一百萬條資料，我們要查的資料正好在最后一個，那么我們是不是一定要從前往后找到這一條資料呢？如果是這樣，我們需要查找的次數就達到了一百萬次，即使是在記憶體中查找，這個效率也是不高的，那么有什么辦法來優化這種情況下的查找效率呢？

頁目錄的引入

我們可以打個比方，我們在看書的時候，如果要找到某一節，而這一節我們并不知道在哪一頁，我們是不是就要從前往后，一節一節地去尋找我們需要的內容的頁碼呢？答案是否定的，因為在書的前面，存在目錄，它會告訴你這一節在哪一頁，例如，第一節在第1頁、第二節在第13頁，在資料庫的頁中，實際上也使用了這種目錄的結構，這就是頁目錄，

那么引入頁目錄之后，我們所理解的頁結構，就變成了這樣：

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

分析一下這張圖，實際上頁目錄就像是我們在看書的時候書本的目錄一樣，目錄項1就相當于第一節，目錄項2就相當于第二節，而每一條資料就相當于書本的每一頁，這張圖就可以解釋成，第一節從第一頁開始，第二節從第三頁開始，而實際上，每個目錄項會存放自己這個目錄項當中最小的id，也就是說，目錄項1中會存放1，而目錄項2會存放3，

那么對比一下資料庫在沒有頁目錄時候的查找流程，假設要查找id=3的資料，在沒有頁目錄的情況下，需要查找id=1、id=2、id=3，三次才能找到該資料，而如果有頁目錄之后，只需要先查看一下id=3存在于哪個目錄項下，然后直接通過目錄項進行資料的查找即可，如果在該目錄項下沒有找到這條資料，那么就可以直接確定這條資料不存在，這樣就大大提升了資料庫的查找效率，但是這種頁目錄的實作，首先就需要基于資料是在已經進行過排序的的場景下，才可以發揮其作用，所以看到這里，大家應該明白第二個問題了，為什么資料庫在插入時會進行排序，這才是真正發揮排序的作用的地方，

頁的擴展

在上文中，我們基本上說明白了MySQL資料庫中頁的概念，以及它是如何基于頁來減少磁盤IO次數的，以及排序是如何優化查詢的效率的，

那么我們現在再來思考第三個問題：在開頭說頁的概念的時候，我們有說過，MySQL中每一頁的大小只有16KB，不會隨著資料的插入而自動擴容，所以這16KB不可能存下我們所有的資料，那么必定會有多個頁來存盤資料，那么在多頁的情況下，MySQL中又是怎么組織這些頁的呢？

針對這個問題，我們繼續來畫出我們現在所了解的多頁的結構圖：

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

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

多頁模式

在多頁模式下，MySQL終于可以完成多資料的存盤了，就是采用開辟新頁的方式，將多條資料放在不同的頁中，然后同樣采用鏈表的資料結構，將每一頁連接起來，那么可以思考第四個問題：多頁情況下是否對查詢效率有影響呢？

多頁模式對于查詢效率的影響

針對這個問題，既然問出來了，那么答案是肯定的，多頁會對查詢效率產生一定的影響，影響主要就體現在，多頁其本質也是一個鏈表結構，只要是鏈表結構，查詢效率一定不會高，

假設資料又非常多條，資料庫就會開辟非常多的新頁，而這些新頁就會像鏈表一樣連接在一起，當我們要在這么多頁中查詢某條資料時，它還是會從頭節點遍歷到存在我們要查找的那條資料所存在的頁上，我們好不容易通過頁目錄優化了頁中資料的查詢效率，現在又出現了以頁為單位的鏈表，這不是前功盡棄了嗎？

如何優化多頁模式

由于多頁模式會影響查詢的效率，那么肯定需要有一種方式來優化多頁模式下的查詢，相信有同學已經猜出來了，既然我們可以用頁目錄來優化頁內的資料區，那么我們也可以采取類似的方式來優化這種多頁的情況，

是的，頁內資料區和多頁模式本質上都是鏈表，那么的確可以采用相同的方式來對其進行優化，它就是目錄頁，

所以我們對比頁內資料區，來分析如何優化多頁結構，在單頁時，我們采用了頁目錄的目錄項來指向一行資料，這條資料就是存在于這個目錄項中的最小資料，那么就可以通過頁目錄來查找所需資料，

所以對于多頁結構也可以采用這種方式，使用一個目錄項來指向某一頁，而這個目錄項存放的就是這一頁中存放的最小資料的索引值，和頁目錄不同的地方在于，這種目錄管理的級別是頁，而頁目錄管理的級別是行，

那么分析到這里，我們多頁模式的結構就會是下圖所示的這樣：

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

存在一個目錄頁來管理頁目錄，目錄頁中的資料存放的就是指向的那一頁中最小的資料，

這里要注意的一點是：其實目錄頁的本質也是頁，普通頁中存的資料是專案資料，而目錄頁中存的資料是普通頁的地址，

假設我們要查找id=19的資料，那么按照以前的查找方式，我們需要從第一頁開始查找，發現不存在那么再到第二頁查找，一直找到第四頁才能找到id=19的資料，但是如果有了目錄頁，就可以使用id=19與目錄頁中存放的資料進行比較，發現19大于任何一條資料，于是進入id=16指向的頁進行查找，直接然后再通過頁內的頁目錄行級別的資料的查找，很快就可以找到id為19的資料了，隨著資料越來越多，這種結構的效率相對于普通的多頁模式，優勢也就越來越明顯，

回歸正題，相信有對MySQL比較了解的同學已經發現了，我們畫的最終的這幅圖，就是MySQL中的一種索引結構——B+樹，

B+樹的引入

B+樹的特點我在《[從入門到入土]令人脫發的資料庫底層設計》已經有詳細敘述過了，在這里就不重復敘述了，如果有不了解的同學可以去看這篇博客，

我們接著往下聊，我們將我們畫的存在目錄頁的多頁模式圖宏觀化，可以形成下面的這張圖：

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

這就是我們兜兜轉轉由簡到繁形成的一顆B+樹，和常規B+樹有些許不同，這是一棵MySQL意義上的B+樹，MySQL的一種索引結構，其中的每個節點就可以理解為是一個頁，而葉子節點也就是資料頁，除了葉子節點以外的節點就是目錄頁，

這一點在圖中也可以看出來，非葉子節點只存放了索引，而只有葉子節點中存放了真實的資料，這也是符合B+樹的特點的，

B+樹的優勢

由于葉子節點上存放了所有的資料，并且有指標相連，每個葉子節點在邏輯上是相連的，所以對于范圍查找比較友好，

B+樹的所有資料都在葉子節點上，所以B+樹的查詢效率穩定，一般都是查詢3次，

B+樹有利于資料庫的掃描，

B+樹有利于磁盤的IO，因為他的層高基本不會因為資料擴大而增高（三層樹結構大概可以存放兩千萬資料量，

頁的完整結構

說完了頁的概念和頁是如何一步一步地組合稱為B+樹的結構之后，相信大家對于頁都有了一個比較清楚的認知，所以這里就要開始說說官方概念了，基于我們上文所說的，給出一個完整的頁結構，也算是對上文中自己理解頁結構的一種補充，

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

上圖為 Page 資料結構，File Header 欄位用于記錄 Page 的頭資訊，其中比較重要的是 FIL_PAGE_PREV 和 FIL_PAGE_NEXT 欄位，通過這兩個欄位，我們可以找到該頁的上一頁和下一頁，實際上所有頁通過兩個欄位可以形成一條雙向鏈表，

Page Header 欄位用于記錄 Page 的狀態資訊，接下來的 Infimum 和 Supremum 是兩個偽行記錄，Infimum（下確界）記錄比該頁中任何主鍵值都要小的值，Supremum （上確界）記錄比該頁中任何主鍵值都要大的值，這個偽記錄分別構成了頁中記錄的邊界，

User Records 中存放的是實際的資料行記錄，具體的行記錄結構將在本文的第二節中詳細介紹，Free Space 中存放的是空閑空間，被洗掉的行記錄會被記錄成空閑空間，Page Directory 記錄著與二叉查找相關的資訊，File Trailer 存盤用于檢測資料完整性的校驗和等資料，
參考來源：https://www.cnblogs.com/bdsir/p/8745553.html

基于B+樹聊聊MySQL的其它知識點

看到這里，我們已經了解了MySQL從單條資料開始，到通過頁來減少磁盤IO次數，并且在頁中實作了頁目錄來優化頁中的查詢效率，然后使用多頁模式來存盤大量的資料，最終使用目錄頁來實作多頁模式的查詢效率并形成我們口中的索引結構——B+樹，既然說到這里了，那我們就來聊聊MySQL的其他知識點，

聚簇索引和非聚簇索引

關于聚簇索引和非聚簇索引在[從入門到入土]令人脫發的資料庫底層設計這篇文章中已經有了詳細的介紹，這里簡單地說說，所謂聚簇索引，就是將索引和資料放到一起，找到索引也就找到了資料，我們剛才看到的B+樹索引就是一種聚簇索引，而非聚簇索引就是將資料和索引分開，查找時需要先查找到索引，然后通過索引回表找到相應的資料，InnoDB有且只有一個聚簇索引，而MyISAM中都是非聚簇索引，

聯合索引的最左前綴匹配原則

在MySQL資料庫中不僅可以對某一列建立索引，還可以對多列建立一個聯合索引，而聯合索引存在一個最左前綴匹配原則的概念，如果基于B+樹來理解這個最左前綴匹配原則，相對來說就會容易很很多了，

首先我們基于文首的這張表建立一個聯合索引：

create index idx_obj on user(age asc,height asc,weight asc)

我們已經了解了索引的資料結構是一顆B+樹，也了解了B+樹優化查詢效率的其中一個因素就是對資料進行了排序，那么我們在創建idx_obj這個索引的時候，也就相當于創建了一顆B+樹索引，而這個索引就是依據聯合索引的成員來進行排序，這里是age,height,weight，

看過我之前那篇博客的同學知道，InnoDB中只要有主鍵被定義，那么主鍵列被作為一個聚簇索引，而其它索引都將被作為非聚簇索引，所以自然而然的，這個索引就會是一個非聚簇索引，

所以根據這些我們可以得出結論：

idx_obj這個索引會根據age,height,weight進行排序
idx_obj這個索引是一個非聚簇索引，查詢時需要回表

根據這兩個結論，首先需要了解的就是，如何排序？

單列排序很簡單，比大小嘛，誰都會，但是多列排序是基于什么原則的呢（重點）？

實際上在MySQL中，聯合索引的排序有這么一個原則，從左往右依次比較大小，就拿剛才建立的索引舉例子，他會先去比較age的大小，如果age的大小相同，那么比較height的大小，如果height也無法比較大小，那么就比較weight的大小，最終對這個索引進行排序，

那么根據這個排序我們也可以畫出一個B+樹，這里就不像上文畫的那么詳細了，簡化一下：

資料：

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

B+樹：

索引很難么？帶你從頭到尾捋一遍MySQL索引結構，不信你學不會！

注意：此時由于是非聚簇索引，所以葉子節點不在有資料，而是存了一個主鍵索引，最侄訓通過主鍵索引來回表查詢資料，

B+樹的結構有了，就可以通過這個來理解最左前綴匹配原則了，

我們先寫一個查詢陳述句

SELECT * FROM user WHERE age=1 and height = 2 and weight = 7

毋庸置疑，這條陳述句一定會走idx_obj這個索引，

那么我們再看一個陳述句：

SELECT * FROM user WHERE height=2 and weight = 7

思考一下，這條SQL會走索引嗎？

答案是否定的，那么我們分析的方向就是，為什么這條陳述句不會走索引，

上文中我們提到了一個多列的排序原則，是從左到右進行比較然后排序的，而我們的idx_obj這個索引從左到右依次是age,height,weight，所以當我們使用height和weight來作為查詢條件時，由于age的缺失，那么就無法從age來進行比較了，

看到這里可能有小伙伴會有疑問，那如果直接用height和weight來進行比較不可以嗎？顯然是不可以的，可以舉個例子，我們把缺失的這一列寫作一個問號，那么這條陳述句的查詢條件就變成了?27，那么我們從這課B+樹的根節點開始，根節點上有127和365，那么以height和weight來進行比較的話，走的一定是127這一邊，但是如果缺失的列數字是大于3的呢？比如427，527，627，那么如果走索引來查詢資料，將會丟失資料，錯誤查詢，所以這種情況下是絕對不會走索引進行查詢的，這就是最左前綴匹配原則的成因，

最左前綴匹配原則，MySQL會一直向右匹配直到遇到范圍查詢（>、<、between、like）就停止匹配，比如 a=3 and b=4 and c>5 and d=6,如果建立(a,b,c,d)順序的索引，d是無法使用索引的，如果建立(a,b,d,c)的索引則都可以使用到，a、b、d的順序可以任意調整，
=和in可以亂序，比如 a=1 and b=2 and c=3 建立(a,b,c)索引可以任意順序，MySQL的查詢優化器會幫你優化成索引可以識別的形式，

根據我們了解的可以得出結論：

只要無法進行排序比較大小的，就無法走聯合索引，

可以再看幾個陳述句：

SELECT * FROM user WHERE age=1 and height = 2

這條陳述句是可以走idx_obj索引的，因為它可以通過比較 (12?<365)，

SELECT * FROM user WHERE age=1 and weight=7

這條陳述句也是可以走ind_obj索引的，因為它也可以通過比較(1?7<365)，走左子樹，但是實際上weight并沒有用到索引，因為根據最左匹配原則，如果有兩頁的age都等于1，那么會去比較height，但是height在這里并不作為查詢條件，所以MySQL會將這兩頁全都加載到記憶體中進行最后的weight欄位的比較，進行掃描查詢，

SELECT * FROM user where age>1

這條陳述句不會走索引，但是可以走索引，這句話是什么意思呢？這條SQL很特殊，由于其存在可以比較的索引，所以它走索引也可以查詢出結果，但是由于這種情況是范圍查詢并且是全欄位查詢，如果走索引，還需要進行回表，MySQL查詢優化器就會認為走索引的效率比全表掃描還要低，所以MySQL會去優化它，讓他直接進行全表掃描，

SELECT * FROM user WEHRE age=1 and height>2 and weight=7

這條陳述句是可以走索引的，因為它可以通過age進行比較，但是weight不會用到索引，因為height是范圍查找，與第二條陳述句類似，如果有兩頁的height都大于2，那么MySQL會將兩頁的資料都加載進記憶體，然后再來通過weight匹配正確的資料，

為什么InnoDB只有一個聚簇索引，而不將所有索引都使用聚簇索引？

因為聚簇索引是將索引和資料都存放在葉子節點中，如果所有的索引都用聚簇索引，則每一個索引都將保存一份資料，會造成資料的冗余，在資料量很大的情況下，這種資料冗余是很消耗資源的，

補充兩個關于索引的點

這兩個點也是上次寫關于索引的博客時漏下的，這里補上，

1.什么情況下會發生明明創建了索引，但是執行的時候并沒有通過索引呢？

科普時間：查詢優化器一條SQL陳述句的查詢，可以有不同的執行方案，至于最終選擇哪種方案，需要通過優化器進行選擇，選擇執行成本最低的方案，

在一條單表查詢陳述句真正執行之前，MySQL的查詢優化器會找出執行該陳述句所有可能使用的方案，對比之后找出成本最低的方案，這個成本最低的方案就是所謂的執行計劃，

優化程序大致如下：

1、根據搜索條件，找出所有可能使用的索引
2、計算全表掃描的代價
3、計算使用不同索引執行查詢的代價
4、對比各種執行方案的代價，找出成本最低的那一個，

參考：https://juejin.im/post/5d23ef4ce51d45572c0600bc

根據我們剛才的那張表的非聚簇索引，這條陳述句就是由于查詢優化器的作用，造成沒有走索引：

SELECT * FROM user where age>1

2.在稀疏索引情況下通常需要通過葉子節點的指標回表查詢資料，什么情況下不需要回表？

科普時間：覆寫索引覆寫索引（covering index）指一個查詢陳述句的執行只用從索引中就能夠取得，不必從資料表中讀取，也可以稱之為實作了索引覆寫，

當一條查詢陳述句符合覆寫索引條件時，MySQL只需要通過索引就可以回傳查詢所需要的資料，這樣避免了查到索引后再回傳表操作，減少I/O提高效率，

如，表covering_index_sample中有一個普通索引 idx_key1_key2(key1,key2)，當我們通過SQL陳述句：select key2 from covering_index_sample where key1 = 'keytest';的時候，就可以通過覆寫索引查詢，無需回表，

參考：https://juejin.im/post/5d23ef4ce51d45572c0600bc

例如:

SELECT age FROM user where age = 1

這句話就不需要進行回表查詢，

結語

本篇文章著重聊了一下關于MySQL的索引結構，從零開始慢慢構建了一個B+樹索引，并且根據這個程序談了B+樹是如何一步一步去優化查詢效率的，

簡單地歸納一下就是：

排序：優化查詢的根本，插入時進行排序實際上就是為了優化查詢的效率，
頁：用于減少IO次數，還可以利用程式區域性原理，來稍微提高查詢效率，
頁目錄：用于規避鏈表的軟肋，避免在查詢時進行鏈表的掃描，
多頁：資料量增加的情況下開辟新頁來保存資料，
目錄頁：“特殊的頁目錄”，其中保存的資料是頁的地址，查詢時可以通過目錄頁快速定位到頁，避免多頁的掃描，

歡迎訪問博客：http://blog.objectspace.cn/

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/97536.html

標籤：MySQL

上一篇：神奇的 SQL 之聯表細節 → MySQL JOIN 的執行程序（一）

下一篇：Mysql 索引