MySQL中事務(wù)持久性的實(shí)現(xiàn)原理是什么？相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

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

InnoDB讀寫(xiě)數(shù)據(jù)原理

Buffer Pool 是位于內(nèi)存的，包含了磁盤(pán)中部分?jǐn)?shù)據(jù)頁(yè)的映射。當(dāng)需要讀取數(shù)據(jù)時(shí)，InnoDB會(huì)首先嘗試從Buffer Pool中讀取，讀取不到的話(huà)就會(huì)從磁盤(pán)讀取后放入Buffer Pool；當(dāng)寫(xiě)入數(shù)據(jù)時(shí)，會(huì)先寫(xiě)入Buffer Pool的頁(yè)面，并把這樣的頁(yè)面標(biāo)記為dirty，并放到專(zhuān)門(mén)的flush list上，這些修改的數(shù)據(jù)頁(yè)會(huì)在后續(xù)某個(gè)時(shí)刻被刷新到磁盤(pán)中（這一過(guò)程稱(chēng)為刷臟，由其他后臺(tái)線(xiàn)程負(fù)責(zé)） 。如下圖所示：

這樣設(shè)計(jì)的好處是可以把大量的磁盤(pán)I/O轉(zhuǎn)成內(nèi)存讀寫(xiě)，并且把對(duì)一個(gè)頁(yè)面的多次修改merge成一次I/O操作（刷臟一次刷入整個(gè)頁(yè)面），避免每次讀寫(xiě)操作都訪(fǎng)問(wèn)磁盤(pán)，從而大大提升了數(shù)據(jù)庫(kù)的性能。

持久性定義

持久性是指事務(wù)一旦提交，它對(duì)數(shù)據(jù)庫(kù)的改變就應(yīng)該是永久性的，接下來(lái)的其他操作或故障不應(yīng)該對(duì)本次事務(wù)的修改有任何影響。

通過(guò)前面的介紹，我們知道InnoDB使用 Buffer Pool  來(lái)提高讀寫(xiě)的性能。但是 Buffer Pool 是在內(nèi)存的，是易失性的，如果一個(gè)事務(wù)提交了事務(wù)后，MySQL突然宕機(jī)，且此時(shí)Buffer Pool中修改的數(shù)據(jù)還沒(méi)有刷新到磁盤(pán)中的話(huà)，就會(huì)導(dǎo)致數(shù)據(jù)的丟失，事務(wù)的持久性就無(wú)法保證。

為了解決這個(gè)問(wèn)題，InnoDB引入了 redo log來(lái)實(shí)現(xiàn)數(shù)據(jù)修改的持久化。當(dāng)數(shù)據(jù)修改時(shí)，InnoDB除了修改Buffer Pool中的數(shù)據(jù)，還會(huì)在redo log 記錄這次操作，并保證redo log早于對(duì)應(yīng)的頁(yè)面落盤(pán)（一般在事務(wù)提交的時(shí)候），也就是常說(shuō)的WAL。若MySQL突然宕機(jī)了且還沒(méi)有把數(shù)據(jù)刷回磁盤(pán)，重啟后，MySQL會(huì)通過(guò)已經(jīng)寫(xiě)入磁盤(pán)的redo log來(lái)恢復(fù)沒(méi)有被刷新到磁盤(pán)的數(shù)據(jù)頁(yè)。

實(shí)現(xiàn)原理：redo log

為了提高性能，和數(shù)據(jù)頁(yè)類(lèi)似，redo log 也包括兩部分：一是內(nèi)存中的日志緩沖(redo log buffer)，該部分日志是易失性的；二是磁盤(pán)上的重做日志文件(redo log file)，該部分日志是持久的。redo log是物理日志，記錄的是數(shù)據(jù)庫(kù)中物理頁(yè)的情況 。

當(dāng)數(shù)據(jù)發(fā)生修改時(shí)，InnoDB不僅會(huì)修改Buffer Pool中的數(shù)據(jù)，也會(huì)在redo log buffer記錄這次操作；當(dāng)事務(wù)提交時(shí)，會(huì)對(duì)redo log buffer進(jìn)行刷盤(pán)，記錄到redo log file中。如果MySQL宕機(jī)，重啟時(shí)可以讀取redo log file中的數(shù)據(jù)，對(duì)數(shù)據(jù)庫(kù)進(jìn)行恢復(fù)。這樣就不需要每次提交事務(wù)都實(shí)時(shí)進(jìn)行刷臟了。

寫(xiě)入過(guò)程

注意點(diǎn)：

• 先修改Buffer Pool，后寫(xiě) redo log buffer。

• redo日志比數(shù)據(jù)頁(yè)先寫(xiě)回磁盤(pán)：事務(wù)提交的時(shí)候，會(huì)把redo log buffer寫(xiě)入redo log file，寫(xiě)入成功才算提交成功（也有其他場(chǎng)景觸發(fā)寫(xiě)入，這里就不展開(kāi)了），而B(niǎo)uffer Pool的數(shù)據(jù)由后臺(tái)線(xiàn)程在后續(xù)某個(gè)時(shí)刻寫(xiě)入磁盤(pán)。

• 刷臟的時(shí)候一定會(huì)保證對(duì)應(yīng)的redo log已經(jīng)落盤(pán)了，也即是所謂的WAL（預(yù)寫(xiě)式日志），否則會(huì)有數(shù)據(jù)丟失的可能性。

  
  

好處

事務(wù)提交的時(shí)候，寫(xiě)入redo log 相比于直接刷臟的好處主要有三點(diǎn)：

刷臟是隨機(jī)I/O，但寫(xiě)redo log 是順序I/O，順序I/O可比隨機(jī)I/O快多了，不需要。
刷臟是以數(shù)據(jù)頁(yè)（Page）為單位的，即使一個(gè)Page只有一點(diǎn)點(diǎn)修改也要整頁(yè)寫(xiě)入；而redo log中只包含真正被修改的部分，數(shù)據(jù)量非常小，無(wú)效IO大大減少。
刷臟的時(shí)候可能要刷很多頁(yè)的數(shù)據(jù)，無(wú)法保證原子性（例如只寫(xiě)了一部分?jǐn)?shù)據(jù)就失敗了），而redo log buffer 向 redo log file 寫(xiě)log block，是按512個(gè)字節(jié)，也就是一個(gè)扇區(qū)的大小進(jìn)行寫(xiě)入，扇區(qū)是寫(xiě)入的最小單位，因此可以保證寫(xiě)入是必定成功的。

先寫(xiě)redo log還是先修改數(shù)據(jù)

一次DML可能涉及到數(shù)據(jù)的修改和redo log的記錄，那它們的執(zhí)行順序是怎么樣的呢？網(wǎng)上的文章有的說(shuō)先修改數(shù)據(jù)，后記錄redo log，有的說(shuō)先記錄redo log，后改數(shù)據(jù)，那真實(shí)的情況是如何呢？

首先通過(guò)上面的說(shuō)明我們知道，redo log buffer在事務(wù)提交的時(shí)候就會(huì)寫(xiě)入redo log file的，而刷臟則是在后續(xù)的某個(gè)時(shí)刻，所以可以確定的是先記錄redo log，后修改data page（WAL當(dāng)然是日志先寫(xiě)啦）。

那接下來(lái)的問(wèn)題就是先寫(xiě)redo log buffer還是先修改Buffer Pool了。要了解這個(gè)問(wèn)題，我們先要了解InnoDB中，一次DML的執(zhí)行過(guò)程是怎么樣的。一次DML的執(zhí)行過(guò)程涉及了數(shù)據(jù)的修改，加鎖，解鎖，redo log的記錄和undo log的記錄等，也是需要保證原子性的，而InnoDB通過(guò)MTR(Mini-transactions)來(lái)保證一次DML操作的原子性。

首先來(lái)看MTR的定義:

 An internal phase of InnoDB processing, when making changes at the physical level to internal data structures during DML operations. A Mini-transactions (mtr) has no notion of rollback; multiple Mini-transactionss can occur within a single transaction. Mini-transactionss write information to the redo log that is used during crash recovery. A Mini-transactions can also happen outside the context of a regular transaction, for example during purge processing by background threads. 見(jiàn) https://dev.mysql.com/doc/refman/8.0/en/glossary.html

MTR 是一個(gè)短原子操作，不能回滾，因?yàn)樗旧砭褪窃拥摹?shù)據(jù)頁(yè)的變更必須通過(guò)MTR，MTR 會(huì)把DML操作對(duì)數(shù)據(jù)頁(yè)的修改記錄到 redo log里。

下面來(lái)簡(jiǎn)單看下MTR的過(guò)程：

• MTR初始化的時(shí)候會(huì)初始化一份 mtr_buf

• 當(dāng)修改數(shù)據(jù)時(shí)，在對(duì)內(nèi)存Buffer Pool中的頁(yè)面進(jìn)行修改的同時(shí)，還會(huì)生成redo log record，保存在mtr_buf中。

• 在執(zhí)行mtr_commit函數(shù)提交本MTR的時(shí)候，會(huì)將mtr_buf中的redo log record更新到redo log buffer中，同時(shí)將臟頁(yè)添加到flush list，供后續(xù)刷臟使用。在log buffer中，每接收到496字節(jié)的log record，就將這組log record包裝一個(gè)12字節(jié)的block header和一個(gè)4字節(jié)的block tailer，成為一個(gè)512字節(jié)的log block，方便刷盤(pán)的時(shí)候?qū)R512字節(jié)刷盤(pán)。

  
  

由此可見(jiàn)，InnoDB是先修改Buffer Pool，后寫(xiě)redo log buffer的。

恢復(fù)數(shù)據(jù)的過(guò)程

在任何情況下，InnoDB啟動(dòng)時(shí)都會(huì)嘗試執(zhí)行recovery操作。在恢復(fù)過(guò)程中，需要redo log參與，而如果還開(kāi)啟了binlog，那就還需要binlog、undo log的參與。因?yàn)橛锌赡軘?shù)據(jù)已經(jīng)寫(xiě)入binlog了，但是redo log還沒(méi)有刷盤(pán)的時(shí)候數(shù)據(jù)庫(kù)就奔潰了（事務(wù)是InnoDB引擎的特性，修改了數(shù)據(jù)不一定提交了，而binlog是MySQL服務(wù)層的特性，修改數(shù)據(jù)就會(huì)記錄了），這時(shí)候就需要redo log，binlog和undo log三者的參與來(lái)判斷是否有還沒(méi)提交的事務(wù)，未提交的事務(wù)進(jìn)行回滾或者提交操作。

下面來(lái)簡(jiǎn)單說(shuō)下僅利用redo log恢復(fù)數(shù)據(jù)的過(guò)程：

• 啟動(dòng)InnoDB時(shí)，找到最近一次Checkpoint的位置，利用Checkpoint LSN去找大于該LSN的redo log進(jìn)行日志恢復(fù)。

• 如果中間恢復(fù)失敗了也沒(méi)影響，再次恢復(fù)的時(shí)候還是從上次保存成功的Checkpoint的位置繼續(xù)恢復(fù)。

  
  

Recover過(guò)程：故障恢復(fù)包含三個(gè)階段：Analysis，Redo和Undo。Analysis階段的任務(wù)主要是利用Checkpoint及Log中的信息確認(rèn)后續(xù)Redo和Undo階段的操作范圍，通過(guò)Log修正Checkpoint中記錄的Dirty Page集合信息，并用其中涉及最小的LSN位置作為下一步Redo的開(kāi)始位置RedoLSN。同時(shí)修正Checkpoint中記錄的活躍事務(wù)集合（未提交事務(wù)），作為Undo過(guò)程的回滾對(duì)象；Redo階段從Analysis獲得的RedoLSN出發(fā)，重放所有的Log中的Redo內(nèi)容，注意這里也包含了未Commit事務(wù)；最后Undo階段對(duì)所有未提交事務(wù)利用Undo信息進(jìn)行回滾，通過(guò)Log的PrevLSN可以順序找到事務(wù)所有需要回滾的修改。具體見(jiàn) http://catkang.github.io/2019/01/16/crash-recovery.html

什么是LSN?

LSN也就是log sequence number，也日志的序列號(hào)，是一個(gè)單調(diào)遞增的64位無(wú)符號(hào)整數(shù)。redo log和數(shù)據(jù)頁(yè)都保存著LSN，可以用作數(shù)據(jù)恢復(fù)的依據(jù)。LSN更大的表示所引用的日志記錄所描述的變化發(fā)生在更后面。

什么是Checkpoint？

Checkpoint表示一個(gè)保存點(diǎn)，在這個(gè)點(diǎn)之前的數(shù)據(jù)頁(yè)的修改（log LSN<Checkpoint LSN）都已經(jīng)寫(xiě)入磁盤(pán)文件了。InnoDB每次刷盤(pán)之后都會(huì)記錄Checkpoint，把新的redo log LSN 記錄到Checkpoint LSN 里，方便恢復(fù)數(shù)據(jù)的時(shí)候作為起始點(diǎn)的判斷。

看完上述內(nèi)容，你們掌握MySQL中事務(wù)持久性的實(shí)現(xiàn)原理是什么的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

網(wǎng)頁(yè)題目：MySQL中事務(wù)持久性的實(shí)現(xiàn)原理是什么-創(chuàng)新互聯(lián)
當(dāng)前路徑：http://www.2m8n56k.cn/article40/cegiho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、定制開(kāi)發(fā)、微信小程序、電子商務(wù)、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：[email protected]。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)