innodb究竟是如何存數(shù)據(jù)的

前言如果你使用過mysql數(shù)據(jù)庫(kù)，對(duì)它的存儲(chǔ)引擎：innodb，一定不會(huì)感到陌生。

眾所周知，在mysql5以前，默認(rèn)的存儲(chǔ)引擎是：myslam。但mysql5之后，默認(rèn)的存儲(chǔ)引擎已經(jīng)變成了：innodb，它是我們建表的首選存儲(chǔ)引擎。

那么，問題來了：

innodb底層是如何存儲(chǔ)數(shù)據(jù)的？

表中有哪些隱藏列？

用戶記錄之間是如何關(guān)聯(lián)起來的？

如果你想知道上面三個(gè)問題的答案，那么，請(qǐng)繼續(xù)往下面看。

本文主要包含如下內(nèi)容：

1.磁盤or內(nèi)存？1.1 磁盤數(shù)據(jù)對(duì)系統(tǒng)來說是非常重要的東西，比如：用戶的身份證、手機(jī)號(hào)、銀行號(hào)、會(huì)員過期時(shí)間、積分等等。一旦丟失，會(huì)對(duì)用戶造成很大的影響。

那么問題來了，如何才能保證這些重要的數(shù)據(jù)不丟呢？

答案：把數(shù)據(jù)存在磁盤上。

當(dāng)然有人會(huì)說，如果磁盤壞了怎么辦？

那就需要備份，或者做主從了。。。

好了，打住，這不是今天的重點(diǎn)。

言歸正傳。

大家都知道，從磁盤上讀寫數(shù)據(jù)，至少需要兩次IO請(qǐng)求才能完成。一次是讀IO，另一次是寫IO。

而IO請(qǐng)求是比較耗時(shí)的操作，如果頻繁的進(jìn)行IO請(qǐng)求勢(shì)必會(huì)影響數(shù)據(jù)庫(kù)的性能。

那么，如何才能解決數(shù)據(jù)庫(kù)的性能問題呢？

1.2 內(nèi)存把數(shù)據(jù)存在寄存器？

沒錯(cuò)，操作系統(tǒng)從寄存器中讀取數(shù)據(jù)是最快的，因?yàn)樗xCPU最近。

但是寄存器有個(gè)非常致命的問題是：它只能存儲(chǔ)非常少量的數(shù)據(jù)，設(shè)計(jì)它的目的主要是用來暫存指令和地址，并非存儲(chǔ)大量用戶數(shù)據(jù)的。

這樣看來，只能把數(shù)據(jù)存在內(nèi)存中了。

因?yàn)閮?nèi)存同樣能滿足我們，快速讀取和寫入數(shù)據(jù)的需求，而且性能是非?？捎^的，只是比較寄存器稍稍慢了一丟丟而已。

不過有個(gè)讓人討厭的地方是，內(nèi)存相對(duì)于磁盤來說，是更加昂貴的資源。通常情況下，500G或者1T的磁盤，是很常見的。但你有聽說過有500G的內(nèi)存嗎？別人會(huì)以為你瘋了。內(nèi)存大小討論的數(shù)量級(jí)一般是16G或32G。

內(nèi)存可以存儲(chǔ)一些用戶數(shù)據(jù)，但無法存儲(chǔ)所有的用戶數(shù)據(jù)，因?yàn)槿绻麛?shù)據(jù)量太大了，它可能還是存不下。

此外，即使用戶數(shù)據(jù)能剛好存在內(nèi)存，以后萬一有一天，數(shù)據(jù)庫(kù)服務(wù)器或者部署節(jié)點(diǎn)掛了，或者重啟了，數(shù)據(jù)不就丟了？

怎么做，才能不會(huì)因?yàn)楫惓Ｇ闆r，而丟數(shù)據(jù)。同時(shí)，又能保證數(shù)據(jù)的讀寫速度呢？

2.數(shù)據(jù)頁(yè)我們可以把一批數(shù)據(jù)放在一起。

寫操作時(shí)，先將數(shù)據(jù)寫到內(nèi)存的某個(gè)批次中，然后再將該批次的數(shù)據(jù)一次性刷到磁盤上。如下圖所示：

讀操作時(shí)，從磁盤上一次讀一批數(shù)據(jù)，然后加載到內(nèi)存當(dāng)中，以后就在內(nèi)存中操作。

將內(nèi)存中的數(shù)據(jù)刷到磁盤，或者將磁盤中的數(shù)據(jù)加載到內(nèi)存，都是以批次為單位，這個(gè)批次就是我們常說的：數(shù)據(jù)頁(yè)。

當(dāng)然innodb中存在多種不同類型的頁(yè)，數(shù)據(jù)頁(yè)只是其中一種，我們?cè)谶@里重點(diǎn)介紹一下數(shù)據(jù)頁(yè)。

那么問題來了，什么是數(shù)據(jù)頁(yè)？

數(shù)據(jù)頁(yè)主要是用來存儲(chǔ)表中記錄的，它在磁盤中是用雙向鏈表相連的，方便查找，能夠非?？焖俚脧囊粋€(gè)數(shù)據(jù)頁(yè)，定位到另一個(gè)數(shù)據(jù)頁(yè)。

很多時(shí)候，由于我們表中的數(shù)據(jù)比較多，在磁盤中可能存放在多個(gè)數(shù)據(jù)頁(yè)當(dāng)中。

有一天，我們要根據(jù)某個(gè)條件查詢數(shù)據(jù)時(shí)，需要從一個(gè)數(shù)據(jù)頁(yè)找到另一個(gè)數(shù)據(jù)頁(yè)，這時(shí)候的雙向鏈表就派上大用場(chǎng)了。

通常情況下，單個(gè)數(shù)據(jù)頁(yè)默認(rèn)的大小是16kb。當(dāng)然，我們也可以通過參數(shù)：innodb_page_size，來重新設(shè)置大小。不過，一般情況下，用它的默認(rèn)值就夠了。

好吧，數(shù)據(jù)頁(yè)的整體結(jié)構(gòu)已經(jīng)搞明白了。

那么，單個(gè)數(shù)據(jù)頁(yè)包含哪些內(nèi)容呢？

從上圖中可以看出，數(shù)據(jù)頁(yè)主要包含如下幾個(gè)部分：

文件頭部

頁(yè)頭部

最大和最小記錄

用戶記錄

空閑空間

頁(yè)目錄

文件尾部

3.用戶記錄對(duì)于新申請(qǐng)的數(shù)據(jù)頁(yè)，用戶記錄是空的。當(dāng)插入數(shù)據(jù)時(shí)，innodb會(huì)將一部分空閑空間分配給用戶記錄。

用戶記錄是innodb的重中之重，我們平時(shí)保存到數(shù)據(jù)庫(kù)中的數(shù)據(jù)，就存儲(chǔ)在它里面。那么，它里面又包含哪些內(nèi)容呢？你不好奇嗎？

其實(shí)在innodb支持的數(shù)據(jù)行格式有四種：

compact行格式

redundant行格式

dynamic行格式

compressed行格式

我們以compact行格式為例：

一條用戶記錄主要包含三部分內(nèi)容：

記錄額外信息，它包含了變長(zhǎng)字段、null值列表和記錄頭信息。

隱藏列，它包含了行id、事務(wù)id和回滾點(diǎn)。

真正的數(shù)據(jù)列，包含真正的用戶數(shù)據(jù)，可以有很多列。

下面讓我們一起了解一下這些內(nèi)容。

3.1 額外信息額外信息并非真正的用戶數(shù)據(jù)，它是為了輔助存數(shù)據(jù)用的。

3.1.1 變長(zhǎng)字段列表

有些數(shù)據(jù)如果直接存會(huì)有問題，比如：如果某個(gè)字段是varchar或text類型，它的長(zhǎng)度不固定，可以根據(jù)存入數(shù)據(jù)的長(zhǎng)度不同，而隨之變化。

如果不在一個(gè)地方記錄數(shù)據(jù)真正的長(zhǎng)度，innodb很可能不知道要分配多少空間。假如都按某個(gè)固定長(zhǎng)度分配空間，但實(shí)際數(shù)據(jù)又沒占多少空間，豈不是會(huì)浪費(fèi)？

所以，需要在變長(zhǎng)字段中記錄某個(gè)變長(zhǎng)字段占用的字節(jié)數(shù)，方便按需分配空間。

3.1.2 null值列表

數(shù)據(jù)庫(kù)中有些字段的值允許為null，如果把每個(gè)字段的null值，都保存到用戶記錄中，顯然有些浪費(fèi)存儲(chǔ)空間。

有沒有辦法只簡(jiǎn)單的標(biāo)記一下，不存儲(chǔ)實(shí)際的null值呢？

答案：將為null的字段保存到null值列表。

在列表中用二進(jìn)制的值1，表示該字段允許為null，用0表示不允許為null。它只占用了1位，就能表示某個(gè)字符是否為null，確實(shí)可以節(jié)省很多存儲(chǔ)空間。

3.1.3 記錄頭信息

記錄頭信息用于描述一些特殊的屬性。

它主要包含：

deleted_flag：即刪除標(biāo)記，用于標(biāo)記該記錄是否被刪除了。

min_rec_flag：即最小目錄標(biāo)記，它是非葉子節(jié)點(diǎn)中的最小目錄標(biāo)記。

n_owned：即擁有的記錄數(shù)，記錄該組索引記錄的條數(shù)。

heap_no：即堆上的位置，它表示當(dāng)前記錄在堆上的位置。

record_type：即記錄類型，其中：0表示普通記錄，1表示非葉子節(jié)點(diǎn)，2表示Infrimum記錄， 3表示Supremum記錄。

next_record：即下一條記錄的位置。

3.2 隱藏列數(shù)據(jù)庫(kù)在保存一條用戶記錄時(shí)，會(huì)自動(dòng)創(chuàng)建一些隱藏列。目前innodb自動(dòng)創(chuàng)建的隱藏列有三種：

db_row_id，即行id，它是一條記錄的唯一標(biāo)識(shí)。

db_trx_id，即事務(wù)id，它是事務(wù)的唯一標(biāo)識(shí)。

db_roll_ptr，即回滾點(diǎn)，它用于事務(wù)回滾。

如果表中有主鍵，則用主鍵做行id，無需額外創(chuàng)建。如果表中沒有主鍵，假如有不為null的unique唯一鍵，則用它做為行id，同樣無需額外創(chuàng)建。

如果表中既沒有主鍵，又沒有唯一鍵，則數(shù)據(jù)庫(kù)會(huì)自動(dòng)創(chuàng)建行id。

也就是說在innodb中，隱藏列中事務(wù)id和回滾點(diǎn)是一定會(huì)被創(chuàng)建的，但行id要根據(jù)實(shí)際情況決定。

3.3 真正數(shù)據(jù)列真正的數(shù)據(jù)列中存儲(chǔ)了用戶的真實(shí)數(shù)據(jù)，它可以包含很多列的數(shù)據(jù)。這個(gè)比較簡(jiǎn)單，沒有什么好多說的。

3.4 用戶記錄是如何相連的？通過上面介紹的內(nèi)容，大家對(duì)一條用戶記錄是如何存儲(chǔ)的，應(yīng)該有了一定的認(rèn)識(shí)。

但問題來了，一條用戶記錄和另一條用戶記錄是如何相連的，innodb是怎么知道，某條記錄的下一條記錄是誰？

答案是：用前面提到過的， 記錄額外信息 》 記錄頭信息 》下一條記錄的位置。

多條用戶記錄之間通過下一條記錄的位置，組成了一個(gè)單向鏈表。這樣就能從前往后，找到所有的記錄了。

4.最大和最小記錄從上面可以得知，在一個(gè)數(shù)據(jù)頁(yè)當(dāng)中，如果存在多條用戶記錄，它們是通過下一條記錄的位置相連的。

不過有個(gè)問題：如果才能快速找到最大的記錄和最小的記錄呢？

這就需要在保存用戶記錄的同時(shí)，也保存最大和最小記錄了。

最大記錄保存到Supremum記錄中。

最小記錄保存在Infimum記錄中。

在保存用戶記錄時(shí)，數(shù)據(jù)庫(kù)會(huì)自動(dòng)創(chuàng)建兩條額外的記錄：Supremum 和 Infimum。

從圖中可以看出用戶數(shù)據(jù)是從最小記錄開始，通過下一條記錄的位置，從小到大，一步步查找，最后找到最大記錄為止。

5.頁(yè)目錄從上面可以看出，如果我們要查詢某條記錄的話，數(shù)據(jù)庫(kù)會(huì)從最小記錄開始，一條條查找所有記錄。如果中途找到了，則直接返回該記錄。如果一直找到最大記錄，還沒有找到想要的記錄，則返回空。

咋一看，沒有問題。

但如果仔細(xì)想想。

效率會(huì)不會(huì)有點(diǎn)低？

這不是要對(duì)整頁(yè)用戶數(shù)據(jù)進(jìn)行掃描嗎？

有沒有更高效的方法？

這就需要使用頁(yè)目錄了。

說白了，就是把一頁(yè)用戶記錄分為若干組，每一組的最大記錄都保存到一個(gè)地方，這個(gè)地方就是頁(yè)目錄。每一組的最大記錄叫做槽。

由此可見，頁(yè)目錄是有多個(gè)槽組成的。

假設(shè)一頁(yè)的數(shù)據(jù)分為4組，這樣在頁(yè)目錄中，就對(duì)應(yīng)了4個(gè)槽，每個(gè)槽中都保存了該組數(shù)據(jù)的最大值。

這樣就能通過二分查找，比較槽中的記錄跟需要找到的記錄的大小。如果用戶需要查找的記錄，小于當(dāng)前槽中的記錄，則向上查找上一個(gè)槽。如果用戶需要查找的記錄，大于當(dāng)前槽中的記錄，則向下查找下一個(gè)槽。

如此一來，就能通過二分查找，快速的定位需要查找的記錄了。

so easy

6.文件頭部和尾部6.1 文件頭部通過前面介紹的行記錄中下一條記錄的位置和頁(yè)目錄，innodb能非?？焖俚亩ㄎ荒骋粭l記錄。但有個(gè)前提條件，就是用戶記錄必須在同一個(gè)數(shù)據(jù)頁(yè)當(dāng)中。

如果用戶記錄非常多，在第一個(gè)數(shù)據(jù)頁(yè)找不到我們想要的數(shù)據(jù)，需要到另外一頁(yè)找該怎么辦呢？

這時(shí)就需要使用文件頭部了。

它里面包含了多個(gè)信息，但我只列出了其中4個(gè)最關(guān)鍵的信息：

頁(yè)號(hào)

上一頁(yè)頁(yè)號(hào)

下一頁(yè)頁(yè)號(hào)

頁(yè)類型

顧名思義，innodb是通過頁(yè)號(hào)、上一頁(yè)頁(yè)號(hào)和下一頁(yè)頁(yè)號(hào)來串聯(lián)不同數(shù)據(jù)頁(yè)的。如下圖所示：不同的數(shù)據(jù)頁(yè)之間，通過上一頁(yè)頁(yè)號(hào)和下一頁(yè)頁(yè)號(hào)構(gòu)成了雙向鏈表。這樣就能從前向后，一頁(yè)頁(yè)查找所有的數(shù)據(jù)了。

此外，頁(yè)類型也是一個(gè)非常重要的字段，它包含了多種類型，其中比較出名的有：數(shù)據(jù)頁(yè)、索引頁(yè)（目錄項(xiàng)頁(yè)）、溢出頁(yè)、undo日志頁(yè)等。

6.2 文件尾部我之前提過，數(shù)據(jù)庫(kù)的數(shù)據(jù)是以數(shù)據(jù)頁(yè)為單位，加載到內(nèi)存中，如果數(shù)據(jù)有更新的話，需要刷新到磁盤上。

但如果某一天比較倒霉，程序在刷新到磁盤的過程中，出現(xiàn)了異常，比如：進(jìn)程被kill掉了，或者服務(wù)器被重啟了。

這時(shí)候數(shù)據(jù)可能只刷新了一部分，如何判斷上次刷盤的數(shù)據(jù)是完整的呢？

這就需要用到文件尾部。

它里面記錄了頁(yè)面的校驗(yàn)和。

在數(shù)據(jù)刷新到磁盤之前，會(huì)先計(jì)算一個(gè)頁(yè)面的校驗(yàn)和。后面如果數(shù)據(jù)有更新的話，會(huì)計(jì)算一個(gè)新值。文件頭部中也會(huì)記錄這個(gè)校驗(yàn)和，由于文件頭部在前面，會(huì)先被刷新到磁盤上。

接下來，刷新用戶記錄到磁盤的時(shí)候，假設(shè)刷新了一部分，恰好程序出現(xiàn)異常了。這時(shí)，文件尾部的校驗(yàn)和，還是一個(gè)舊值。數(shù)據(jù)庫(kù)會(huì)去校驗(yàn)，文件尾部的校驗(yàn)和，不等于文件頭部的新值，說明該數(shù)據(jù)頁(yè)的數(shù)據(jù)是不完整的。

7.頁(yè)頭部通過上面介紹的內(nèi)容，數(shù)據(jù)頁(yè)之間能夠輕松訪問了，但剩下還有個(gè)比較重要的問題，就是記錄的狀態(tài)信息。

比如一頁(yè)數(shù)據(jù)到底保存了多條記錄，或者頁(yè)目錄到底使用了多個(gè)槽等。這些信息是實(shí)時(shí)統(tǒng)計(jì)，還是事先統(tǒng)計(jì)好了，保存到某個(gè)地方？

為了性能考慮，上面的這些統(tǒng)計(jì)數(shù)據(jù)，當(dāng)然是先統(tǒng)計(jì)好，保存到一個(gè)地方。后面需要用到該數(shù)據(jù)時(shí)，再讀取出來會(huì)更好。這個(gè)保存統(tǒng)計(jì)數(shù)據(jù)的地方，就是頁(yè)頭部。

當(dāng)然頁(yè)頭部不僅僅只保存：槽的數(shù)量、記錄條數(shù)等信息。

它還記錄了：

已刪除記錄所占的字節(jié)數(shù)

最后插入記錄的位置

最大事務(wù)id

索引id

索引層級(jí)

其實(shí)還有很多，在這里就不一一列舉了，有興趣的朋友可以找我私聊。

總結(jié)多個(gè)數(shù)據(jù)頁(yè)之間通過頁(yè)號(hào)構(gòu)成了雙向鏈表。而每一個(gè)數(shù)據(jù)頁(yè)的行數(shù)據(jù)之間，又通過下一條記錄的位置構(gòu)成了單項(xiàng)鏈表。

參考：《mysql是怎樣運(yùn)行的》

編輯：jq