清空認知，而後從新理解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;
複製代碼

能夠看到，數據已經完整地放到了咱們建立的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實際上就是在咱們插入數據的時候，就幫咱們在頁中排好了序，至於爲何要排序，這裏先賣個關子，接着往下看。

排序對性能的影響

上文中咱們提了一個問題，爲何數據庫在插入數據時要對其進行排序呢？咱們按正常順序插入數據不是頁挺好的嗎？

這就要涉及到一個數據庫查詢流程的問題了，不管如何，咱們是絕對不會去無緣無故地在插入數據時增長一個操做來讓流程複雜化的，因此插入數據時排序必定有其目的，就是優化查詢的效率。

而咱們不難看出，頁內部存放數據的模塊，實質上就是一個鏈表的結構，鏈表的特色也就是增刪快，查詢慢，因此優化查詢的效率是必須的。

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

  仍是基於咱們第一節中的那張頁圖來談，咱們插入了五條數據，id分別是從1-5，那麼假設我要找一個表中不存在的id，假設id=-1，那麼如今的查詢流程就是：

  將id=1的這一整頁數據取出，進行逐個比對，那麼當咱們找到id=1的這條數據時，發現這個id大於咱們所須要找的哪一個id，因爲數據庫在插入數據時，已經進行過排序了，那麼在id=1的數據後面，都是id>1的數據，因此咱們就不須要再繼續往下尋找了。

  若是在插入時沒有進行排序，那毋庸置疑，咱們須要再繼續往下進行尋找，逐條查找直到到結尾也沒有找到這條數據，才能返回不存在這條數據。

固然，這只是排序優化的冰山一角，接着往下看。

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

說完了排序，下面就來分析一下咱們在第一節中的那幅圖，對於大數據量下有什麼弊端，或者換一個說法，咱們能夠怎麼對這個模式進行優化。

咱們不難看出，在現階段咱們瞭解的頁模式中，只有一個功能，就是在查詢某條數據的時候直接將一整頁的數據加載到內存中，以減小硬盤IO次數，從而提升性能。可是，咱們也能夠看到，如今的頁模式內部，其實是採用了鏈表的結構，前一條數據指向後一條數據，本質上仍是經過數據的逐條比較來取出特定的數據。那麼假設，咱們這一頁中有一百萬條數據，咱們要查的數據正好在最後一個，那麼咱們是否是必定要從前日後找到這一條數據呢？若是是這樣，咱們須要查找的次數就達到了一百萬次，即便是在內存中查找，這個效率也是不高的。那麼有什麼辦法來優化這種狀況下的查找效率呢？

頁目錄的引入

咱們能夠打個比方，咱們在看書的時候，若是要找到某一節，而這一節咱們並不知道在哪一頁，咱們是否是就要從前日後，一節一節地去尋找咱們須要地內容地頁碼呢？答案是否認的，由於在書的前面，存在目錄，它會告訴你這一節在哪一頁，例如，第一節在第1頁、第二節在第13頁。在數據庫的頁中，實際上也使用了這種目錄的結構，這就是頁目錄。

那麼引入頁目錄以後，咱們所理解的頁結構，就變成了這樣：

分析一下這張圖，實際上頁目錄就像是咱們在看書的時候書本的目錄同樣，目錄項1就至關於第一節，目錄項2就至關於第二節，而每一條數據就至關於書本的每一頁，這張圖就能夠解釋成，第一節從第一頁開始，第二節從第三頁開始，而實際上，每一個目錄項會存放本身這個目錄項當中最小的id，也就是說，目錄項1中會存放1，而目錄項2會存放3。

那麼對比一下數據庫在沒有頁目錄時候的查找流程，假設要查找id=3的數據，在沒有頁目錄的狀況下，須要查找id=一、id=二、id=3，三次才能找到該數據，而若是有頁目錄以後，只須要先查看一下id=3存在於哪一個目錄項下，而後直接經過目錄項進行數據的查找便可，若是在該目錄項下沒有找到這條數據，那麼就能夠直接肯定這條數據不存在，這樣就大大提高了數據庫的查找效率，可是這種頁目錄的實現，首先就須要基於數據是在已經進行過排序的的場景下，才能夠發揮其做用，因此看到這裏，你們應該明白第二個問題了，爲何數據庫在插入時會進行排序，這纔是真正發揮排序的做用的地方。

頁的擴展

在上文中，咱們基本上說明白了MySQL數據庫中頁的概念，以及它是如何基於頁來減小磁盤IO次數的，以及排序是如何優化查詢的效率的。那麼咱們如今再來思考第三個問題：在開頭說頁的概念的時候，咱們有說過，MySQL中每一頁的大小隻有16KB，不會隨着數據的插入而自動擴容，因此這16KB不可能存下咱們全部的數據，那麼一定會有多個頁來存儲數據，那麼在多頁的狀況下，MySQL中又是怎麼組織這些頁的呢？

針對這個問題，咱們繼續來畫出咱們如今所瞭解的多頁的結構圖：

能夠看到，在數據不斷變多的狀況下，MySQL會再去開闢新的頁來存放新的數據，而每一個頁都有指向下一頁的指針和指向上一頁的指針，將全部頁組織起來（這裏修改了一下數據，將每一列的數據都放到了數據區中，其中第一個空格以前的表明id），第一頁中存放id爲1-5的數據，第二頁存放id爲6-10的數據，第三頁存放id爲11-15的數據，須要注意的是在開闢新頁的時候，咱們插入的數據不必定是放在新開闢的頁上，而是要進行全部頁的數據比較，來決定這條插入的數據放在哪一頁上，而完成數據插入以後，最終的多頁結構就會像上圖中畫的那樣。

多頁模式

在多頁模式下，MySQL終於能夠完成多數據的存儲了，就是採用開闢新頁的方式，將多條數據放在不一樣的頁中，而後一樣採用鏈表的數據結構，將每一頁鏈接起來。那麼能夠思考第四個問題：多頁狀況下是否對查詢效率有影響呢？

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

  針對這個問題，既然問出來了，那麼答案是確定的，多頁會對查詢效率產生必定的影響，影響主要就體如今，多頁其本質也是一個鏈表結構，只要是鏈表結構，查詢效率必定不會高。假設數據又很是多條，數據庫就會開闢很是多的新頁，而這些新頁就會像鏈表同樣鏈接在一塊兒，當咱們要在這麼多頁中查詢某條數據時，它仍是會從頭節點遍歷到存在咱們要查找的那條數據所存在的頁上，咱們好不容易經過頁目錄優化了頁中數據的查詢效率，如今又出現了以頁爲單位的鏈表，這不是前功盡棄了嗎？

• 如何優化多頁模式

  因爲多頁模式會影響查詢的效率，那麼確定須要有一種方式來優化多頁模式下的查詢。相信有同窗已經猜出來了，既然咱們能夠用頁目錄來優化頁內的數據區，那麼咱們也能夠採起相似的方式來優化這種多頁的狀況。是的，頁內數據區和多頁模式本質上都是鏈表，那麼的確能夠採用相同的方式來對其進行優化，它就是目錄頁。

  因此咱們對比頁內數據區，來分析如何優化多頁結構。在單頁時，咱們採用了頁目錄的目錄項來指向一行數據，這條數據就是存在於這個目錄項中的最小數據，那麼就能夠經過頁目錄來查找所需數據。因此對於多頁結構也能夠採用這種方式，使用一個目錄項來指向某一頁，而這個目錄項存放的就是這一頁中存放的最小數據的索引值。和頁目錄不一樣的地方在於，這種目錄管理的級別是頁，而頁目錄管理的級別是行。

  那麼分析到這裏，咱們多頁模式的結構就會是下圖所示的這樣：

  

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

  這裏要注意的一點是：其實目錄頁的本質也是頁，普通頁中存的數據是項目數據，而目錄頁中存的數據是普通頁的地址。

  假設咱們要查找id=19的數據，那麼按照之前的查找方式，咱們須要從第一頁開始查找，發現不存在那麼再到第二頁查找，一直找到第四頁才能找到id=19的數據，可是若是有了目錄頁，就可使用id=19與目錄頁中存放的數據進行比較，發現19大於任何一條數據，因而進入id=16指向的頁進行查找，直接而後再經過頁內的頁目錄行級別的數據的查找，很快就能夠找到id爲19的數據了。隨着數據愈來愈多，這種結構的效率相對於普通的多頁模式，優點也就愈來愈明顯。

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

B+樹的引入

B+樹的特色我在《[從入門到入土]使人脫髮的數據庫底層設計》已經有詳細敘述過了，在這裏就不重複敘述了，若是有不瞭解的同窗能夠去看這篇博客。

咱們接着往下聊，咱們將咱們畫的存在目錄頁的多頁模式圖宏觀化，能夠造成下面的這張圖：

這就是咱們兜兜轉轉由簡到繁造成的一顆B+樹。和常規B+樹有些許不一樣，這是一棵MySQL意義上的B+樹，MySQL的一種索引結構，其中的每一個節點就能夠理解爲是一個頁，而葉子節點也就是數據頁，除了葉子節點之外的節點就是目錄頁。這一點再圖中也能夠看出來，非葉子節點只存放了索引，而只有葉子節點中存放了真實的數據，這也是符合B+樹的特色的。

• B+樹的優點

  1. 因爲葉子節點上存放了全部的數據，而且有指針相連，每一個葉子節點在邏輯上是相連的，因此對於範圍查找比較友好。
  2. B+樹的全部數據都在葉子節點上，因此B+樹的查詢效率穩定，通常都是查詢3次。
  3. B+樹有利於數據庫的掃描。
  4. B+樹有利於磁盤的IO，由於他的層高基本不會由於數據擴大而增高（三層樹結構大概能夠存放兩千萬數據量。

頁的完整結構

說完了頁的概念和頁是如何一步一步地組合稱爲B+樹的結構以後，相信你們對於頁都有了一個比較清楚的認知，因此這裏就要開始說說官方概念了，基於咱們上文所說的，給出一個完整的頁結構，也算是對上文中本身理解頁結構的一種補充。

上圖爲 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 存儲用於檢測數據完整性的校驗和等數據。

來源:www.cnblogs.com/bdsir/p/874…

基於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中只要有主鍵被定義，那麼主鍵列被做爲一個聚簇索引，而其它索引都將被做爲非聚簇索引，因此天然而然的，這個索引就會是一個非聚簇索引。

  因此根據這些咱們能夠得出結論：

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

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

  單列排序很簡單，比大小嘛，誰都會，可是多列排序時基於什麼原則的呢（重點）？

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

  那麼根據這個排序咱們也能夠畫出一個B+樹，這裏就不像上文畫的那麼詳細了，簡化一下：

  數據：

  

  B+樹：

  

  注意：此時因爲時非聚簇索引，因此葉子節點不在有數據，而是存了一個主鍵索引，最終會經過主鍵索引來回表查詢數據。

  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，那麼若是走索引來查詢數據，將會丟失數據，錯誤查詢。因此這種狀況下是絕對不會走索引進行查詢的。這就是最左前綴匹配原則的成因。

  1.最左前綴匹配原則，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的順序能夠任意調整。 2.=和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的查詢優化器會找出執行該語句全部可能使用的方案，對比以後找出成本最低的方案。這個成本最低的方案就是所謂的執行計劃。 優化過程大體以下： 一、根據搜索條件，找出全部可能使用的索引 二、計算全表掃描的代價 三、計算使用不一樣索引執行查詢的代價 四、對比各類執行方案的代價，找出成本最低的那一個 。 參考連接：juejin.im/post/5d23ef…

   根據咱們剛纔的那張表的非聚簇索引，這條語句就是因爲查詢優化器的做用，形成沒有走索引：

   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';的時候，就能夠經過覆蓋索引查詢，無需回表。 參考連接：juejin.im/post/5d23ef…

   例如:

   SELECT age FROM user where age = 1
   複製代碼

   這句話就不須要進行回表查詢。

結語

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

簡單地概括一下就是：

排序：優化查詢的根本，插入時進行排序實際上就是爲了優化查詢的效率。

頁：用於減小IO次數，還能夠利用程序局部性原理，來稍微提升查詢效率。

頁目錄：用於規避鏈表的軟肋，避免在查詢時進行鏈表的掃描。

多頁：數據量增長的狀況下開闢新頁來保存數據。

目錄頁：「特殊的頁目錄」，其中保存的數據是頁的地址。查詢時能夠經過目錄頁快速定位到頁，避免多頁的掃描。

歡迎你們訪問個人我的博客：Object's Blog