目錄數(shù)據(jù)表的文件構(gòu)成表空間的組成結(jié)構(gòu)段區(qū)頁行InnoDB 行格式類型Compact 行格式圖解記錄的額外信息記錄的真實(shí)數(shù)據(jù)總結(jié)數(shù)據(jù)表的文件構(gòu)成

Mysql的存儲行為是由Innodb存儲引擎去具體實(shí)現(xiàn)的，在windows下安裝Mysql后有data（數(shù)據(jù)庫存放的地方）的文件夾，linux一般在/var/lib/mysql文件件。

創(chuàng)建數(shù)據(jù)庫和表后我們可以在data目錄先看到數(shù)據(jù)庫對應(yīng)名稱文件夾，文件夾有opt、frm、ibd三種文件：

db.opt，用來存儲當(dāng)前數(shù)據(jù)庫的默認(rèn)字符集和字符校驗(yàn)規(guī)則。demo1.frm ，t_order 的表結(jié)構(gòu)會保存在這個(gè)文件demo1.ibd，t_order 的表數(shù)據(jù)會保存在這個(gè)文件。表數(shù)據(jù)既可以存在共享表空間文件（文件名：ibdata1，在data目錄下）里，也可以存放在獨(dú)占表空間文件（文件名：表名字.ibd）

表空間的組成結(jié)構(gòu)

先看圖，先對表空間結(jié)構(gòu)做個(gè)大概了解，形成一個(gè)概念

段

InnoDB存儲引擎中，對段的管理都是由引擎自身所完成，我們已看到段有幾種類型，它是不同類型的區(qū)組成的集合，一般分為索引段（B+樹非葉子節(jié)點(diǎn)區(qū)）、數(shù)據(jù)段（B+樹非葉子節(jié)點(diǎn)區(qū)）、回滾段（回滾數(shù)據(jù)區(qū)）。

也就是說InnoDB 對 B+ 樹的葉節(jié)點(diǎn)和葉子節(jié)點(diǎn)進(jìn)行了區(qū)別對待，也就是說葉子節(jié)點(diǎn)有自己獨(dú)有的區(qū)，非葉子節(jié)點(diǎn)也有自己獨(dú)有的區(qū)，如果不區(qū)分葉子節(jié)點(diǎn)和非葉子節(jié)點(diǎn)，統(tǒng)統(tǒng)把節(jié)點(diǎn)代表的頁面放到申請到的區(qū)中的話，進(jìn)行范圍掃描的效率就大幅降低，而不同的區(qū)的集合就組成了不同的段。

區(qū)

我們知道B+樹的每一層中的頁都會形成一個(gè)雙向鏈表，如果是以頁為單位來分配存儲空間的話，雙向鏈表相鄰的兩個(gè)頁之間的物理位置可能不是連續(xù)的，也許離得非常遠(yuǎn)，這種情況下進(jìn)行 隨機(jī)I/O 是會很慢的。

因此，應(yīng)該盡量讓鏈表中相鄰的頁的物理位置也相鄰，這樣進(jìn)行范圍查詢的時(shí)候才可以使用所謂的 順序I/O。

區(qū)在物理位置上由連續(xù)的64個(gè)頁組成，InnoDB 中的頁大小默認(rèn)是 16KB，所以一個(gè)區(qū)的大小是 64*16KB= 1MB，這樣使得頁的雙向鏈表在物理位置也是相鄰的，從而進(jìn)行順序I/O，加快了查詢效率！

在表數(shù)據(jù)量大的時(shí)候，為某個(gè)索引分配空間的時(shí)候就不再按照頁為單位分配了，而是按區(qū)為單位分配，甚至在表中的數(shù)據(jù)特別多的時(shí)候，可以一次性分配多個(gè)連續(xù)的區(qū)。

頁

Innodb讀取數(shù)據(jù)的時(shí)候，并不是按照行來讀取數(shù)據(jù)的，InnoDB 的數(shù)據(jù)是按【頁】為單位來讀寫的，當(dāng)需要讀一條記錄的時(shí)候，并不是將這個(gè)行記錄從磁盤讀出來，而是以頁為單位，將其整體讀入內(nèi)存。

InnoDB 的數(shù)據(jù)是按【頁】為單位來讀寫的，也就是說，當(dāng)需要讀一條記錄的時(shí)候，并不是將這個(gè)行記錄從磁盤讀出來，而是以頁為單位，將其整體讀入內(nèi)存。默認(rèn)每個(gè)頁的大小為 16KB，也就是最多能保證 16KB 的連續(xù)存儲空間。頁是 InnoDB 存儲引擎磁盤管理的最小單元，數(shù)據(jù)庫每次讀寫都是以【頁】為單位的，一次最少從磁盤中讀取 16K 的內(nèi)容到內(nèi)存中。行

MySQL也是以【行 row】進(jìn)行存儲的，圖中對于行的描畫圖是 COMPACT格式，這也是重點(diǎn)需要了解的格式，而不同的行格式，存儲的結(jié)構(gòu)也不同。

InnoDB 行格式類型

行格式：就是記錄在磁盤上的存放形式或者說存儲結(jié)構(gòu)

InnoDB 存儲引擎設(shè)計(jì)了 4 種行格式，分別是 Redundant、Compact、Dynamic和 Compressed ，后三個(gè)都是緊湊型行格式，為的是存放更多的行記錄。

Redundant 行格式比較古老了， MySQL 5.0 版本之前用的行格式，現(xiàn)在基本不用了，我們知道有這個(gè)格式就行了

Compact 行格式在MySQL 5.0 之后引入，在MySQL5.1版本中，默認(rèn)設(shè)置為Compact行格式，一條完整的記錄其實(shí)可以被分為記錄的額外信息和記錄的真實(shí)數(shù)據(jù)兩大部分。

Dynamic 和 Compressed 它們的行格式都和 Compact 挺像，只是在 處理溢出列數(shù)據(jù)和Compact不同 ，MySQL5.7 版本之后，默認(rèn)使用 Dynamic 行格式。

Compact 行格式圖解

從上面我們知道Compact和Dynamic 和 Compressed很像，那么我們就Compact行格式展開進(jìn)一步了解，了解了Compact就等同于對其他也做了了解。

從圖中我們可以看到Compact行格式下，一條記錄分為 【記錄的額外信息】和【記錄的真實(shí)數(shù)據(jù)】兩部分，我們的列數(shù)據(jù)是在真實(shí)數(shù)據(jù)部分，我們再分別對這些內(nèi)容進(jìn)行更具體的描述。

記錄的額外信息

額外信息為的是更好的管理記錄，分為變長字段長度列表、NULL值列表、記錄頭信息

我們來創(chuàng)建一個(gè)表來看看變長字段具體是存的，表結(jié)構(gòu)如下，行格式 Compact，本文對于行記錄的實(shí)際存儲案例基于這張表：

CREATE TABLE `demo1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `col1` varchar(45) COLLATE utf8_bin DEFAULT NULL, `col2` varchar(45) COLLATE utf8_bin DEFAULT NULL, `col3` int(11) DEFAULT NULL, `col4` char(5) COLLATE utf8_bin DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=ascii ROW_FORMAT=COMPACT;

并插入三條數(shù)據(jù)，demo1表中的各個(gè)列都使用的是ascii字符集（每個(gè)字符只需要1個(gè)字節(jié)來進(jìn)行編碼）

1：變長字段列信息

針對VARCHAR、TEXT、BLOB這類變長字段，列中實(shí)際存儲了多少數(shù)據(jù)是不固定的，因此除了要把數(shù)據(jù)本身存下來，還需要記下它的長度，COMPACT將變長列的實(shí)際長度按照字段的順序，逆序存儲在變長字段長度列表里。

變長字段存儲空間分為兩部分：真正的數(shù)據(jù)部分、該數(shù)據(jù)占用的字節(jié)數(shù)

從demo1表的第一條記錄來看各個(gè)字段占用的字節(jié)數(shù)，因?yàn)槭亲冮L字段， id、col3(int)、col(char)這三個(gè)字段可以不用管

clo1字段是varchar ，值是zs，占用兩個(gè)字節(jié)的空間，十六進(jìn)制 0x02；clo2字段是varchar ，值是lsa，占用三個(gè)字節(jié)的空間，十六進(jìn)制 0x03；

第一行行記錄填入變長字段長度列表后的示意圖如下：

逆序排列的目的是為了讓位置靠前的記錄的真實(shí)數(shù)據(jù)和數(shù)據(jù)對應(yīng)的字段長度信息可以同時(shí)在一個(gè) CPU Cache Line 中，這樣就可以提高 CPU Cache 的命中率

2：NULL值列表

當(dāng)某些字段是null值時(shí)，才顯示在null值列表null值列表是通過bit位來進(jìn)行標(biāo)識的，一個(gè)字段占一個(gè)比特位，bit位按字段逆序排列字段值為null的bit位為1，否則為0null 值列表必須用整數(shù)個(gè)字節(jié)的位表示（1字節(jié)8位），如果使用的二進(jìn)制位個(gè)數(shù)不足整數(shù)個(gè)字節(jié)，則在字節(jié)的高位補(bǔ) 0

要注意的是null值列表并不是固定的1個(gè)字節(jié)，如果一條記錄中有9個(gè)字段的值都是null，那么null值列表大小將是兩個(gè)字節(jié)大小，依次類推。

結(jié)合這些特性，我們來看看一條記錄中存在null值和不存在null值在null值列表中的樣子，我們記錄使用上面表demo1的結(jié)構(gòu)和數(shù)據(jù)，其中id是主鍵不能為null，不在討論范圍內(nèi)，表中null字段不超過8個(gè)，這三條記錄對應(yīng)的null值列表如下：

第一條記錄：

第二條記錄：

第三條記錄：

3：記錄頭信息

記錄頭其實(shí)包含了很多信息，如圖，我們著重了解紅色部分幾個(gè)比較重要的。

delete_flag ：刪除標(biāo)記 0未刪除、1已刪除，我們執(zhí)行 detele 刪除記錄的時(shí)候，并不會真正的刪除記錄，只是將這個(gè)記錄的 delete_flag 標(biāo)記為 1。 (所有的被刪除掉的記錄會組成一個(gè)垃圾鏈表，記錄在這個(gè)鏈表中占用的空間被稱為可重用空間。之后若是有新的記錄插入到表中，它們就可以覆蓋掉被刪除的這些記錄占用的存儲空間了)next_record：記錄與記錄之間是通過鏈表組織的，它表示當(dāng)前記錄的真實(shí)數(shù)據(jù)到下一條記錄的真實(shí)數(shù)據(jù)的距離，指向的是下一條記錄的「記錄頭信息」和「真實(shí)數(shù)據(jù)」之間的位置。 這個(gè)位置剛好向左讀就是記錄頭信息，向右讀就是真實(shí)數(shù)據(jù)，該值為【正】表示下一條記錄在它的后面，為【負(fù)】表示下一條記錄在它的前面（這里都是按字節(jié)去找位置）record_type：表示當(dāng)前記錄的類型，0：表示普通記錄，1：表示B+樹非葉子節(jié)點(diǎn)記錄，2：表示最小記錄(Infimum)，3：表示最大記錄(Supremum)記錄的真實(shí)數(shù)據(jù)

我們看隱藏字段 row_id、trx_id、roll_ptr 感覺是不是在哪里遇到過，只要你了解過Mysql的MVCC機(jī)制就很熟悉這幾個(gè)字段

row_id：如果我們指定了主鍵或者唯一約束列，那么就沒有 row_id 隱藏字段了。如果既沒有指定主鍵，又沒有唯一約束，InnoDB 才會為記錄添加 row_id 隱藏字段。row_id不是必需的，占用 6 個(gè)字節(jié)。trx_id：記錄創(chuàng)建這條記錄/最后一次修改該記錄的事務(wù) ID， trx_id是必需的，占用 6 個(gè)字節(jié)。roll_ptr：回滾指針，記錄的是記錄上一個(gè)版本的指針，roll_ptr 是必需的，占用 7 個(gè)字節(jié)。

其他字段就是我們創(chuàng)建表的時(shí)候定義的各個(gè)列字段了。

總結(jié)

通篇下來，感覺對InnoDB實(shí)際的存儲結(jié)構(gòu)有了更深的認(rèn)識，當(dāng)然也會產(chǎn)生不少問題，比如：

1：一行記錄除了 TEXT、BLOBs 類型的列，限制最大為 65535 字節(jié)，那么能具體分析分析嗎？

2：行溢出了會怎么樣，因?yàn)橐豁摼?6kb，16384字節(jié)，是小于65535 字節(jié)的

3：為什么設(shè)計(jì)表的時(shí)候字段會選擇not null？

等等，這些問題將會在下次進(jìn)行總結(jié)，就不在這里用大篇幅展開了。

到此這篇關(guān)于MySQL InnoDB行記錄存儲結(jié)構(gòu)分析的文章就介紹到這了,更多相關(guān)MySQL InnoDB存儲結(jié)構(gòu)內(nèi)容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！