這篇文章主要講解了“InnoDB的外存數(shù)據(jù)結(jié)構(gòu)介紹”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“InnoDB的外存數(shù)據(jù)結(jié)構(gòu)介紹”吧！

創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),岢嵐企業(yè)網(wǎng)站建設(shè),岢嵐品牌網(wǎng)站建設(shè),網(wǎng)站定制,岢嵐網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,岢嵐網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

PartⅠ 表和表空間

“Everything is a file…”這句至理名言告訴我們一切都得從文件說(shuō)起。那么對(duì) InnoDB 外存數(shù)據(jù)結(jié)構(gòu)的學(xué)習(xí)，我們也先從表和文件開(kāi)始。

一、表 ( Table )

當(dāng)我們使用 CREATE TABLE 創(chuàng)建一個(gè)表時(shí)，MySQL 會(huì)創(chuàng)建一個(gè) .frm 文件和一個(gè) .ibd 文件。.frm 文件是描述表結(jié)構(gòu)定義的文件，而 .ibd 文件是 InnoDB 引擎層特有的，用于記錄InnoDB表的數(shù)據(jù)。舉個(gè)例子，在 db.CCCtest 下創(chuàng)建一個(gè)表”jersey_test”，建表語(yǔ)句如下：

CREATE TABLE `jersey_test` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `requestId` char(64) NOT NULL COMMENT 'request',
  `type` smallint(6) NOT NULL DEFAULT '0' COMMENT '類型',
  `name` varchar(64) NOT NULL COMMENT 'name',
  PRIMARY KEY (`id`),
  KEY `request` (`requestId`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

同時(shí)，我們往表中插入一條記錄如下：

[ jersey_test 表中的數(shù)據(jù) ]

我們進(jìn)入到 MySQL 的 /data 目錄下面，可以看到”jersey_test.frm”文件和”jersey_test.ibd”文件。

[ CCCtest 庫(kù)中的文件 ]

.frm 文件是二進(jìn)制格式的，我們通過(guò) hexdump 工具稍加分析，可以看到文件中除了一些編碼信息外，主要內(nèi)容就是表結(jié)構(gòu)信息。

[ .frm 文件內(nèi)容 ]

這和我們使用 DESC TABLE 語(yǔ)法看到的表結(jié)構(gòu)描述一致。

[ 表結(jié)構(gòu)描述 ]

數(shù)據(jù)文件 .ibd 的分析與之類似。

二、Row Formats

InnoDB 中的表都是分文件存儲(chǔ)的，表中的行數(shù)據(jù)也按照相應(yīng)的格式記錄在文件中。這里我們簡(jiǎn)要?dú)w納一下 InnoDB 所支持的文件存儲(chǔ)格式和行存儲(chǔ)格式。InnoDB 的文件格式由參數(shù) innodb_file_format 指定，它支持 Antelope 和 Barracuda 兩種文件格式。Barracuda 是新的文件格式，它是包含 Antelope 格式在內(nèi)的。Antelope 文件格式支持兩種行存儲(chǔ)格式，Compact 和 Redundant ，Barracuda 支持的新的行存儲(chǔ)格式為 Compressed 和 Dynamic。

[ InnoDB行存儲(chǔ)格式 ]

InnoDB 表的行存儲(chǔ)格式由參數(shù) innodb_default_row_format 指定，在 5.7 版本中的默認(rèn)值為 Dynamic 。行存儲(chǔ)格式?jīng)Q定了表中的記錄在文件中是如何進(jìn)行存儲(chǔ)的，不同的行存儲(chǔ)格式有其特殊的優(yōu)勢(shì)和劣勢(shì)，也會(huì)影響數(shù)據(jù)庫(kù)的行為。例如，使用 Compressed 這種格式可以使行記錄有更高的壓縮比，如果一個(gè)物理頁(yè)能存放的行記錄越多，它的索引或記錄查找會(huì)更快，內(nèi)存消耗也會(huì)更小，但是壓縮數(shù)據(jù)本身也會(huì)帶回額外的系統(tǒng)開(kāi)銷。另外一個(gè)需要注意的地方是，在進(jìn)行數(shù)據(jù)庫(kù)表遷移時(shí)，需要關(guān)注源實(shí)例和目標(biāo)實(shí)例的 Row Format 是否匹配。比如你有一個(gè) MyISAM 的表要遷移到 InnoDB 上，并且 MyISAM 表的 Row Format 為默認(rèn)值 Fixed ，此時(shí)需要改成 Dynamic ，因?yàn)檫@兩種格式對(duì)變長(zhǎng)字段如 varchar/blob/text 等的處理是不一致的。

三、表空間 ( TableSpace )

我們前面談到，InnoDB 每個(gè)表都有自己獨(dú)立的文件，其實(shí)是用到了它的默認(rèn)行為，即使用獨(dú)立表空間，它由參數(shù) innodb_file_per_table 控制。事實(shí)上 InnoDB 包含多種表空間類型，包括系統(tǒng)表空間 ( System TableSpace )，獨(dú)立表空間 ( File-Per-Table TableSpace ) 和通用表空間 ( General TableSpace ) 等。

系統(tǒng)表空間存儲(chǔ)了 InnoDB 的數(shù)據(jù)字典（元數(shù)據(jù)信息），系統(tǒng)表，雙寫緩沖區(qū) ( doublewrite buffer )，Change Buffer 等。如果將參數(shù) innodb_file_per_table 置為 OFF ，即所有的表數(shù)據(jù)都存儲(chǔ)在系統(tǒng)表空間中。但是在使用 InnoDB 時(shí)，更推薦的方法是將 innodb_file_per_table 置為 ON，即使用獨(dú)立表空間，它有如下幾個(gè)好處：

1. 當(dāng)使用 Truncate Table 和 Drop Table 命令刪除表時(shí)，系統(tǒng)會(huì)直接刪除表的數(shù)據(jù)文件，即回收物理空間。而使用系統(tǒng)表空間則無(wú)法回收這些物理空間；

2. 和上面類似，當(dāng)使用重建表的語(yǔ)法時(shí)，如 OPTIMIZE TABLE 或者 ALTER TABLE ENGINE = InnoDB 時(shí)，系統(tǒng)也能夠回收物理空間；

3. 可以單獨(dú)將某個(gè)表指定到對(duì)應(yīng)的存儲(chǔ)位置，這個(gè)存儲(chǔ)位置可以不在 MySQL 的數(shù)據(jù)目錄下。比如你想使用 RAID 或者 SSD 來(lái)存儲(chǔ)某個(gè)表，當(dāng)你使用獨(dú)立表空間時(shí)，就可以通過(guò) CREATE TABLE … DATA DIRECTORY 這個(gè)語(yǔ)法來(lái)實(shí)現(xiàn)。

使用獨(dú)立表空間也有一些潛在的問(wèn)題。例如，每個(gè)表都有自己的單獨(dú)的文件，容易造成物理空間的浪費(fèi)，如果數(shù)據(jù)庫(kù)有很多小表的話，這種空間浪費(fèi)也會(huì)比較明顯。通用表空間 ( General TableSpace ) 可以緩解這個(gè)問(wèn)題。通用表空間可以認(rèn)為是 all-in-one (系統(tǒng)表空間) 和 file-per-table 的一個(gè)折中，它允許你使用 CREATE TABLESPACE 語(yǔ)法創(chuàng)建一個(gè)大的空間，然后你可以向這個(gè)空間中添加一些表的數(shù)據(jù)文件進(jìn)行存儲(chǔ)，這些表的數(shù)據(jù)文件是共享存儲(chǔ)空間的。

Part Ⅱ 索引

索引可以說(shuō)是 InnoDB 最重要的數(shù)據(jù)結(jié)構(gòu)，介紹數(shù)據(jù)庫(kù)索引的資料也很多，談點(diǎn)題外話，什么是索引呢？索引其實(shí)就是幫助我們快速查找到數(shù)據(jù)( data ) 的輔助結(jié)構(gòu)，可以說(shuō)有數(shù)據(jù)的地方就需要索引。比如在文件系統(tǒng)里，數(shù)據(jù)的索引保存在元數(shù)據(jù) inode 信息中，它記錄著這個(gè)文件所有的數(shù)據(jù)頁(yè)( data pages ) 具體在哪個(gè)位置，比如文件有10個(gè)頁(yè)，它就對(duì)應(yīng)記錄10個(gè)頁(yè)框的物理地址。文件系統(tǒng)的索引當(dāng)然也會(huì)有直接索引和間接索引，因?yàn)槿绻苯铀饕b不下，就會(huì)用二級(jí)索引來(lái)裝，其結(jié)構(gòu)如下圖所示，

[ 文件系統(tǒng) inode 結(jié)構(gòu) ]

操作系統(tǒng)中最常見(jiàn)（也可能是最快）的索引大概是虛擬地址到物理地址的映射表。之所以快，首先在于它是連續(xù)的，當(dāng)你進(jìn)行跨頁(yè)訪問(wèn)的時(shí)候不需要去計(jì)算下一個(gè)頁(yè)的地址，另外地址的轉(zhuǎn)換是由專門的硬件MMU來(lái)做的，硬件肯定更快?？梢栽O(shè)想一下，如果文件存儲(chǔ)或者數(shù)據(jù)庫(kù)存儲(chǔ)的索引也采用虛擬地址映射表加上硬件加速的話，肯定會(huì)比現(xiàn)有的方式更快。虛擬地址直接映射到進(jìn)程地址空間還可以減少進(jìn)入內(nèi)核態(tài)的開(kāi)銷。

說(shuō)回 InnoDB 的索引結(jié)構(gòu)，InnoDB 的索引采用 B+ 樹(shù)這種數(shù)據(jù)結(jié)構(gòu)，InnoDB 表中的行數(shù)據(jù)都是由聚簇索引 ( clustered index ) 組織的，它也被稱作主鍵索引 ( primar key )，即主鍵索引這棵 B+ 樹(shù)的葉子節(jié)點(diǎn)存儲(chǔ)的是主鍵對(duì)應(yīng)的整行數(shù)據(jù)。為 InnoDB 的每個(gè)表都建立自增的主鍵索引非常重要，之所以需要自增，是因?yàn)樵诓迦胄掠涗洉r(shí)可以做到連續(xù)，追加插入，這樣可以減少索引查找和索引頁(yè)分裂所帶來(lái)的額外開(kāi)銷。InnoDB 其他的索引稱為二級(jí)索引 ( secondary index )，二級(jí)索引的葉子節(jié)點(diǎn)存儲(chǔ)的是主鍵索引的值，因此，絕大多數(shù)使用二級(jí)索引查詢記錄時(shí)，都會(huì)先通過(guò)二級(jí)索引找到主鍵索引的值，再通過(guò)主鍵索引找到行記錄。

Part Ⅲ 恢復(fù)日志

一、重做日志和回滾日志 ( Redo Log & Undo Log )

在 InnoDB 中，數(shù)據(jù)一致性由 Redo Log 來(lái)保證，它使用的是 WAL(Write-Ahead Logging) 機(jī)制，即先寫日志再寫數(shù)據(jù)。InnoDB 使用這種方式在進(jìn)行故障恢復(fù)時(shí)，會(huì)將 Redo Log 中的日志重做一遍，也就是將系統(tǒng)中未提交的事務(wù)重新執(zhí)行。默認(rèn)情況下，Redo Log 記錄在磁盤的 ib_logfile0 和 ib_logfile1 這兩個(gè)文件里，MySQL 循環(huán)的寫這兩個(gè)文件，因此，Redo Log 會(huì)有寫滿的情況，這里就需要介紹日志中的 checkpoint 機(jī)制。checkpoint 記錄了整個(gè)系統(tǒng)當(dāng)前日志已經(jīng)同步到的位置，也就是說(shuō)，在 checkpoint 之前的事務(wù)都是已經(jīng)提交的事務(wù)，數(shù)據(jù)不會(huì)存在不一致的情況。而當(dāng) MySQL 寫入 Redo Log 記錄追上 checkpoint 時(shí)，Redo Log 就寫滿了，此時(shí)需要等待 Redo Log 同步數(shù)據(jù)并釋放空間。

另一方面，在數(shù)據(jù)庫(kù)這種存儲(chǔ)系統(tǒng)中，更新操作失敗并回滾的情況是很常見(jiàn)的，所以需要特別關(guān)注這種情況，Undo Log 就是用來(lái)解決這個(gè)問(wèn)題。Undo Log 記錄的是當(dāng)一個(gè)更新操作失敗需要回滾時(shí)，應(yīng)該進(jìn)行哪些反向操作。即當(dāng)你 insert 一條記錄時(shí)，Undo log中會(huì)記錄一條對(duì)應(yīng)的 delete 記錄，反之亦然。

二、Binlog

Redo Log 解決了本地?cái)?shù)據(jù)（這里是指單點(diǎn)實(shí)例）一致性的問(wèn)題。但是數(shù)據(jù)庫(kù)要做到高可用，還需要考慮多副本或跨區(qū)跨地域容災(zāi)。MySQL Binlog 就提供了這種能力，Binlog 支持 Statement，Row 和 Mixed 三種模式。其中， Row 模式會(huì)記錄每行數(shù)據(jù)的修改操作，相比 Statement 模式，它能保證主從復(fù)制的正確性。

前面已經(jīng)提到，Redo Log 和 Binlog 必須同時(shí)使用才能做到數(shù)據(jù)一致且高可用。接下來(lái)簡(jiǎn)要分析一下數(shù)據(jù)庫(kù)進(jìn)行插入或更新操作時(shí)是如何做到這一點(diǎn)的。MySQL 使用 WAL 機(jī)制進(jìn)行更新操作，即先寫 Redo Log 和 Binlog，然后再寫數(shù)據(jù)。寫 Redo Log 和 Binlog 必須保證原子性，要么都更新成功，要么都更新失敗，否則會(huì)造成本地?cái)?shù)據(jù)和其他副本數(shù)據(jù)不一致的情況。更新 Redo Log 和 Binlog 的過(guò)程稱為兩階段提交，其步驟為：

1. 先將更新的操作寫到 Redo Log，此時(shí)流程標(biāo)記為 prepare 狀態(tài)；

2. 更新 Binlog，此時(shí)需將 BinLog 刷回磁盤才能視為成功；

3. 提交事務(wù)（此時(shí)還會(huì)清除該事務(wù) Undo 日志），流程標(biāo)記為 commit 狀態(tài)。

兩階段提交可以保證數(shù)據(jù)的一致性，它在任何一個(gè)階段異常失敗都可以進(jìn)行恢復(fù)。比如，如果事務(wù)已經(jīng)是 commit 狀態(tài)，此時(shí)Redo Log 和 Binlog 都已更新成功；如果是在 prepare 狀態(tài)，此時(shí)就需要判斷 BinLog 中是否有完整的信息，如果有，則會(huì)進(jìn)行 commit，如果沒(méi)有完整信息，則整個(gè)事務(wù)回滾。

感謝各位的閱讀，以上就是“InnoDB的外存數(shù)據(jù)結(jié)構(gòu)介紹”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)InnoDB的外存數(shù)據(jù)結(jié)構(gòu)介紹這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！