MySQL InnoDB行記錄存儲(chǔ)結(jié)構(gòu)分析
Mysql的存儲(chǔ)行為是由Innodb存儲(chǔ)引擎去具體實(shí)現(xiàn)的，在windows下安裝Mysql后有data（數(shù)據(jù)庫存放的地方）的文件夾，linux一般在/var/lib/mysql文件件。
創(chuàng)建數(shù)據(jù)庫和表后我們可以在data目錄先看到數(shù)據(jù)庫對(duì)應(yīng)名稱文件夾，文件夾有opt、frm、ibd三種文件：
db.opt，用來存儲(chǔ)當(dāng)前數(shù)據(jù)庫的默認(rèn)字符集和字符校驗(yàn)規(guī)則。demo1.frm ，t_order 的表結(jié)構(gòu)會(huì)保存在這個(gè)文件demo1.ibd，t_order 的表數(shù)據(jù)會(huì)保存在這個(gè)文件。表數(shù)據(jù)既可以存在共享表空間文件（文件名：ibdata1，在data目錄下）里，也可以存放在獨(dú)占表空間文件（文件名：表名字.ibd）
先看圖，先對(duì)表空間結(jié)構(gòu)做個(gè)大概了解，形成一個(gè)概念
InnoDB存儲(chǔ)引擎中，對(duì)段的管理都是由引擎自身所完成，我們已看到段有幾種類型，它是不同類型的區(qū)組成的集合，一般分為索引段（B+樹非葉子節(jié)點(diǎn)區(qū)）、數(shù)據(jù)段（B+樹非葉子節(jié)點(diǎn)區(qū)）、回滾段（回滾數(shù)據(jù)區(qū)）。
也就是說InnoDB 對(duì) B+ 樹的葉節(jié)點(diǎn)和葉子節(jié)點(diǎn)進(jìn)行了區(qū)別對(duì)待，也就是說葉子節(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ǐng)到的區(qū)中的話，進(jìn)行范圍掃描的效率就大幅降低，而不同的區(qū)的集合就組成了不同的段。
區(qū)我們知道B+樹的每一層中的頁都會(huì)形成一個(gè)雙向鏈表，如果是以頁為單位來分配存儲(chǔ)空間的話，雙向鏈表相鄰的兩個(gè)頁之間的物理位置可能不是連續(xù)的，也許離得非常遠(yuǎn)，這種情況下進(jìn)行 隨機(jī)I/O 是會(huì)很慢的。
因此，應(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ù)存儲(chǔ)空間。頁是 InnoDB 存儲(chǔ)引擎磁盤管理的最小單元，數(shù)據(jù)庫每次讀寫都是以【頁】為單位的，一次最少從磁盤中讀取 16K 的內(nèi)容到內(nèi)存中。行MySQL也是以【行 row】進(jìn)行存儲(chǔ)的，圖中對(duì)于行的描畫圖是 COMPACT格式，這也是重點(diǎn)需要了解的格式，而不同的行格式，存儲(chǔ)的結(jié)構(gòu)也不同。
InnoDB 行格式類型行格式：就是記錄在磁盤上的存放形式或者說存儲(chǔ)結(jié)構(gòu)
InnoDB 存儲(chǔ)引擎設(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就等同于對(duì)其他也做了了解。
從圖中我們可以看到Compact行格式下，一條記錄分為 【記錄的額外信息】和【記錄的真實(shí)數(shù)據(jù)】?jī)刹糠郑覀兊牧袛?shù)據(jù)是在真實(shí)數(shù)據(jù)部分，我們?cè)俜謩e對(duì)這些內(nèi)容進(jìn)行更具體的描述。
記錄的額外信息額外信息為的是更好的管理記錄，分為變長(zhǎng)字段長(zhǎng)度列表、NULL值列表、記錄頭信息
我們來創(chuàng)建一個(gè)表來看看變長(zhǎng)字段具體是存的，表結(jié)構(gòu)如下，行格式 Compact，本文對(duì)于行記錄的實(shí)際存儲(chǔ)案例基于這張表：
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：變長(zhǎng)字段列信息
針對(duì)VARCHAR、TEXT、BLOB這類變長(zhǎng)字段，列中實(shí)際存儲(chǔ)了多少數(shù)據(jù)是不固定的，因此除了要把數(shù)據(jù)本身存下來，還需要記下它的長(zhǎng)度，COMPACT將變長(zhǎng)列的實(shí)際長(zhǎng)度按照字段的順序，逆序存儲(chǔ)在變長(zhǎng)字段長(zhǎng)度列表里。
變長(zhǎng)字段存儲(chǔ)空間分為兩部分：真正的數(shù)據(jù)部分、該數(shù)據(jù)占用的字節(jié)數(shù)
從demo1表的第一條記錄來看各個(gè)字段占用的字節(jié)數(shù)，因?yàn)槭亲冮L(zhǎng)字段， id、col3(int)、col(char)這三個(gè)字段可以不用管
clo1字段是varchar ，值是zs，占用兩個(gè)字節(jié)的空間，十六進(jìn)制 0x02；clo2字段是varchar ，值是lsa，占用三個(gè)字節(jié)的空間，十六進(jìn)制 0x03；第一行行記錄填入變長(zhǎng)字段長(zhǎng)度列表后的示意圖如下：
逆序排列的目的是為了讓位置靠前的記錄的真實(shí)數(shù)據(jù)和數(shù)據(jù)對(duì)應(yīng)的字段長(zhǎng)度信息可以同時(shí)在一個(gè) CPU Cache Line 中，這樣就可以提高 CPU Cache 的命中率
2：NULL值列表
當(dāng)某些字段是null值時(shí)，才顯示在null值列表null值列表是通過bit位來進(jìn)行標(biāo)識(shí)的，一個(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è)，這三條記錄對(duì)應(yīng)的null值列表如下：
第一條記錄：
第二條記錄：
第三條記錄：
3：記錄頭信息
記錄頭其實(shí)包含了很多信息，如圖，我們著重了解紅色部分幾個(gè)比較重要的。
我們看隱藏字段 row_id、trx_id、roll_ptr 感覺是不是在哪里遇到過，只要你了解過Mysql的MVCC機(jī)制就很熟悉這幾個(gè)字段
其他字段就是我們創(chuàng)建表的時(shí)候定義的各個(gè)列字段了。
總結(jié)通篇下來，感覺對(duì)InnoDB實(shí)際的存儲(chǔ)結(jié)構(gòu)有了更深的認(rèn)識(shí)，當(dāng)然也會(huì)產(chǎn)生不少問題，比如：
1：一行記錄除了 TEXT、BLOBs 類型的列，限制最大為 65535 字節(jié)，那么能具體分析分析嗎？
2：行溢出了會(huì)怎么樣，因?yàn)橐豁摼?6kb，16384字節(jié)，是小于65535 字節(jié)的
3：為什么設(shè)計(jì)表的時(shí)候字段會(huì)選擇not null？
等等，這些問題將會(huì)在下次進(jìn)行總結(jié)，就不在這里用大篇幅展開了。
到此這篇關(guān)于MySQL InnoDB行記錄存儲(chǔ)結(jié)構(gòu)分析的文章就介紹到這了,更多相關(guān)MySQL InnoDB存儲(chǔ)結(jié)構(gòu)內(nèi)容請(qǐng)搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！
網(wǎng)公網(wǎng)安備