帶你從頭到尾捋一遍MySQL索引結構

這次把資料庫中最核心的也是最難搞懂的內容，也就是索引，分享給大家。

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

從乙個簡單的表開始

create table user(

id int primary key,
age int,
height int,
weight int,
name varchar(32)
)engine = innodb;

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

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好像悄悄的給我們按照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實際上就是在我們插入資料的時候，就幫我們在頁中排好了序，至於為什麼要排序，這裡先賣個關子，接著往下看。

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

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

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

還是基於我們第一節中的那張頁圖來談，我們插入了五條資料，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=1、id=2、id=3，三次才能找到該資料，而如果有頁目錄之後，只需要先檢視一下id=3存在於哪個目錄項下，然後直接通過目錄項進行資料的查詢即可，如果在該目錄項下沒有找到這條資料，那麼就可以直接確定這條資料不存在，這樣就大大提公升了資料庫的查詢效率，但是這種頁目錄的實現，首先就需要基於資料是在已經進行過排序的的場景下，才可以發揮其作用，所以看到這裡，大家應該明白第二個問題了，為什麼資料庫在插入時會進行排序，這才是真正發揮排序的作用的地方。

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

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

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

從頭到尾寫SQL 一

大二的時候學長說，要學東西真的要從頭到尾寫到部落格上，現在作為大五老學渣來看，真的好有道理。那就從這個貼開始吧，寫乙個sql的系列。現在來看，怎樣能把計算機內的各種資料儲存在一起並且將之分類呢？資料庫提供了很好的解決辦法，廣義上資料庫就是存放資料的倉庫，便於我們查詢歸納。當資料越來越多時，你會發現使...

從頭到尾談一下HTTPS

你能談一下https嗎？一種比http安全的協議。如果面試這樣說的話那差不多就gg了，其實https要展開回答的話內容還挺豐富的。本篇文章詳細介紹了https是什麼 為什麼安全以及實現安全的方法，一起來學習吧。本文略長，請保持耐心。https是以安全為目標的http通道，簡單講是http的安全版。之...

從頭到尾 餐飲管理系統 （一）

從頭到尾 餐飲管理系統 一 1 出這套教程的目的，一方面是希望能夠激起大家對軟體開發的熱情和積極性，另一方面是把我對軟體開發的一些心得和知識分享給大家。這套教程如果對您有所幫助，萬分榮幸，若有不當之處，還望見諒 勿噴 的情況下，您可以自由的 分發 傳播此教程。與我取得聯絡，本人將萬分感激！1 系統預...