任何一個技術(shù)都有其底層的關(guān)鍵基礎(chǔ)技術(shù)，這些關(guān)鍵技術(shù)很有可能也是其他技術(shù)的關(guān)鍵技術(shù)，學(xué)習(xí)這些底層技術(shù)，就可以一通百通，讓你很快的掌握其他技術(shù)。如何在磁盤上存儲數(shù)據(jù)，如何使用日志文件保證數(shù)據(jù)不丟失以及如何落盤，不僅是MySQL等數(shù)據(jù)庫的關(guān)鍵技術(shù)，也是MQ消息隊列或者其他中間件的關(guān)鍵技術(shù)之一。

上圖詳細顯示了InnoDB存儲引擎的體系架構(gòu)，從圖中可見，InnoDB存儲引擎由內(nèi)存池，后臺線程和磁盤文件三大部分組成。接下來我們就來簡單了解一下磁盤文件相關(guān)的概念和原理。

InnoDB的主要的磁盤文件主要分為三大塊：一是系統(tǒng)表空間，二是用戶表空間，三是redo日志文件和歸檔文件。二進制文件(binlog)等文件是MySQL Server層維護的文件，所以未列入InnoDB的磁盤文件中。

系統(tǒng)表空間和用戶表空間

InnoDB系統(tǒng)表空間包含InnoDB數(shù)據(jù)字典(元數(shù)據(jù)以及相關(guān)對象)并且doublewrite buffer,change buffer,undo logs的存儲區(qū)域。系統(tǒng)表空間也默認包含任何用戶在系統(tǒng)表空間創(chuàng)建的表數(shù)據(jù)和索引數(shù)據(jù)。系統(tǒng)表空間是一個共享的表空間因為它是被多個表共享的

系統(tǒng)表空間是由一個或者多個數(shù)據(jù)文件組成。默認情況下,1個初始大小為10MB，名為ibdata1的系統(tǒng)數(shù)據(jù)文件在MySQL的data目錄下被創(chuàng)建。用戶可以使用innodb_data_file_path對數(shù)據(jù)文件的大小和數(shù)量進行配置。

innodbdatafile_path的格式如下：

innodb_data_file_path=datafile1[,datafile2]...

用戶可以通過多個文件組成一個表空間，同時制定文件的屬性：

innodb_data_file_path = /db/ibdata1:1000M;/dr2/db/ibdata2:1000M:autoextend

這里講/db/ibdata1和/dr2/db/ibdata2兩個文件組成系統(tǒng)表空間。如果這兩個文件位于不同的磁盤上，磁盤的負載可能被平均，因此可以提高數(shù)據(jù)庫的整體性能。兩個文件的文件名之后都跟了屬性，表示文件ibdata1的大小為1000MB，文件ibdata2的大小為1000MB，而且用完空間之后可以自動增長(autoextend)。

設(shè)置innodbdatafilepath參數(shù)之后，所以基于InnoDB存儲引擎的表的數(shù)據(jù)都會記錄到該系統(tǒng)表空間中，如果設(shè)置了參數(shù)innodbfilepertable，則用戶可以將每個基于InnoDB存儲引擎的表產(chǎn)生一個獨立的用戶表空間。用戶表空間的命名規(guī)則為：表名.ibd。

通過這種方式，用戶不用將所有數(shù)據(jù)都存放于默認的系統(tǒng)表空間中，但是用戶表空只存儲該表的數(shù)據(jù)、索引和插入緩沖BITMAP等信息，其余信息還是存放在默認的表空間中。

上圖顯示InnoDB存儲引擎對于文件的存儲方式，其中frm文件是表結(jié)構(gòu)定義文件，記錄每個表的表結(jié)構(gòu)定義。

重做日志文件和歸檔文件

默認情況下，在InnoDB存儲引擎的數(shù)據(jù)目錄下會有兩個名為iblogfile0和iblogfile1的文件，這就是InnoDB的重做日志文件(redo log file)，它記錄了對于InnoDB存儲引擎的事務(wù)日志。 當(dāng)InnoDB的數(shù)據(jù)存儲文件發(fā)生錯誤時，重做日志文件就能派上用場。InnoDB存儲引擎可以使用重做日志文件將數(shù)據(jù)恢復(fù)為正確狀態(tài)，以此來保證數(shù)據(jù)的正確性和完整性。

每個InnoDB存儲引擎至少有1個重做日志文件組(group)，每個文件組下至少有2個重做日志文件，如默認的iblogfile0和iblogfile1。

為了得到更高的可靠性，用戶可以設(shè)置多個鏡像日志組，將不同的文件組放在不同的磁盤上，以此來提高重做日志的高可用性。

在日志組中每個重做日志文件的大小一致，并以循環(huán)寫入的方式運行。InnoDB存儲引擎先寫入重做日志文件1，當(dāng)文件被寫滿時，會切換到重做日志文件2，再當(dāng)重做日志文件2也被寫滿時，再切換到重做日志文件1。

用戶可以使用innodb_log_file_size來設(shè)置重做日志文件的大小，這對InnoDB存儲引擎的性能有著非常大的影響。默認8MB。

如果重做日志文件設(shè)置的太大，數(shù)據(jù)丟失時，恢復(fù)時可能需要很長的時間；另一方面，如果設(shè)置的太小，重做日志文件太小會導(dǎo)致依據(jù)checkpoint的檢查需要頻繁刷新臟頁到磁盤中，導(dǎo)致性能的抖動。

重做日志相關(guān)和Checkpoint的機制可以閱讀之前文章的相應(yīng)章節(jié)。

MySQL探秘(三):InnoDB的內(nèi)存結(jié)構(gòu)和特性

重做日志的落盤機制

InnoDB對于數(shù)據(jù)文件和日志文件的刷盤遵守WAL(Write ahead redo log) 和Force-log-at-commit兩種規(guī)則，二者保證了事務(wù)的持久性。WAL要求數(shù)據(jù)的變更寫入到磁盤前，首先必須將內(nèi)存中的重做日志寫入到磁盤；Force-log-at-commit要求當(dāng)一個事務(wù)提交時，所有產(chǎn)生的重做日志都必須刷新到磁盤上，如果日志刷新成功后，緩沖池中的數(shù)據(jù)刷新到磁盤前數(shù)據(jù)庫發(fā)生了宕機，那么重啟時，數(shù)據(jù)庫可以從重做日志中恢復(fù)數(shù)據(jù)。

如上圖所示，InnoDB在緩沖池中變更數(shù)據(jù)時，會首先將相關(guān)變更寫入重做日志緩沖中，然后再按時或者當(dāng)事務(wù)提交時寫入磁盤，這符合Force-log-at-commit原則；當(dāng)重做日志寫入磁盤后，緩沖池中的變更數(shù)據(jù)才會依據(jù)checkpoint機制擇時寫入到磁盤中，這符合WAL原則。 在checkpoint擇時機制中，就有重做日志文件寫滿的判斷，所以，如前文所述，如果重做日志文件太小，經(jīng)常被寫滿，就會頻繁導(dǎo)致checkpoint將更改的數(shù)據(jù)寫入磁盤，導(dǎo)致性能抖動。

操作系統(tǒng)的文件系統(tǒng)是帶有緩存的，當(dāng)InnoDB向磁盤寫入數(shù)據(jù)時，有可能只是寫入到了文件系統(tǒng)的緩存中，沒有真正的“落袋為安”。

InnoDB的innodb_flush_log_at_trx_commit屬性可以控制每次事務(wù)提交時InnoDB的行為。當(dāng)屬性值為0時，事務(wù)提交時，不會對重做日志進行寫入操作，而是等待主線程按時寫入；當(dāng)屬性值為1時，事務(wù)提交時，會將重做日志寫入文件系統(tǒng)緩存，并且調(diào)用文件系統(tǒng)的fsync，將文件系統(tǒng)緩沖中的數(shù)據(jù)真正寫入磁盤存儲，確保不會出現(xiàn)數(shù)據(jù)丟失；當(dāng)屬性值為2時，事務(wù)提交時，也會將日志文件寫入文件系統(tǒng)緩存，但是不會調(diào)用fsync，而是讓文件系統(tǒng)自己去判斷何時將緩存寫入磁盤。日志的刷盤機制如下圖所示。

innodb_flush_log_at_trx_commit是InnoDB性能調(diào)優(yōu)的一個基礎(chǔ)參數(shù)，涉及InnoDB的寫入效率和數(shù)據(jù)安全。當(dāng)參數(shù)值為0時，寫入效率最高，但是數(shù)據(jù)安全最低；參數(shù)值為1時，寫入效率最低，但是數(shù)據(jù)安全最高；參數(shù)值為2時，二者都是中等水平。一般建議將該屬性值設(shè)置為1，以獲得較高的數(shù)據(jù)安全性，而且也只有設(shè)置為1，才能保證事務(wù)的持久性。

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的MySQL探秘(四):InnoDB的磁盘文件及落盘机制（持久性）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。