這篇文章將為大家詳細(xì)講解有關(guān)MySQL中undo log 及 redo log是什么，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

讓客戶(hù)滿(mǎn)意是我們工作的目標(biāo)，不斷超越客戶(hù)的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶(hù)，將通過(guò)不懈努力成為客戶(hù)在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名與空間、虛擬空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、嘉興網(wǎng)站維護(hù)、網(wǎng)站推廣。

00 – Undo Log
Undo Log 是為了實(shí)現(xiàn)事務(wù)的原子性，在MySQL數(shù)據(jù)庫(kù)InnoDB存儲(chǔ)引擎中，還用Undo Log來(lái)實(shí)現(xiàn)多版本并發(fā)控制(簡(jiǎn)稱(chēng)：MVCC)。

- 事務(wù)的原子性(Atomicity)
  事務(wù)中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在執(zhí)行的過(guò)程中發(fā)生
  了錯(cuò)誤，要回滾(Rollback)到事務(wù)開(kāi)始前的狀態(tài)，就像這個(gè)事務(wù)從來(lái)沒(méi)有執(zhí)行過(guò)。

- 原理
  Undo Log的原理很簡(jiǎn)單，為了滿(mǎn)足事務(wù)的原子性，在操作任何數(shù)據(jù)之前，首先將數(shù)據(jù)備份到一個(gè)地方
  （這個(gè)存儲(chǔ)數(shù)據(jù)備份的地方稱(chēng)為Undo Log）。然后進(jìn)行數(shù)據(jù)的修改。如果出現(xiàn)了錯(cuò)誤或者用戶(hù)執(zhí)行了
  ROLLBACK語(yǔ)句，系統(tǒng)可以利用Undo Log中的備份將數(shù)據(jù)恢復(fù)到事務(wù)開(kāi)始之前的狀態(tài)。

除了可以保證事務(wù)的原子性，Undo Log也可以用來(lái)輔助完成事務(wù)的持久化。

- 事務(wù)的持久性(Durability)
  事務(wù)一旦完成，該事務(wù)對(duì)數(shù)據(jù)庫(kù)所做的所有修改都會(huì)持久的保存到數(shù)據(jù)庫(kù)中。為了保證持久性，數(shù)據(jù)庫(kù)
  系統(tǒng)會(huì)將修改后的數(shù)據(jù)完全的記錄到持久的存儲(chǔ)上。

- 用Undo Log實(shí)現(xiàn)原子性和持久化的事務(wù)的簡(jiǎn)化過(guò)程
  假設(shè)有A、B兩個(gè)數(shù)據(jù)，值分別為1,2。
  A.事務(wù)開(kāi)始.
  B.記錄A=1到undo log.
  C.修改A=3.
  D.記錄B=2到undo log.
  E.修改B=4.
  F.將undo log寫(xiě)到磁盤(pán)。
  G.將數(shù)據(jù)寫(xiě)到磁盤(pán)。
  H.事務(wù)提交
  這里有一個(gè)隱含的前提條件：‘?dāng)?shù)據(jù)都是先讀到內(nèi)存中，然后修改內(nèi)存中的數(shù)據(jù)，最后將數(shù)據(jù)寫(xiě)回磁盤(pán)’。

  之所以能同時(shí)保證原子性和持久化，是因?yàn)橐韵绿攸c(diǎn)：
  A. 更新數(shù)據(jù)前記錄Undo log。
  B. 為了保證持久性，必須將數(shù)據(jù)在事務(wù)提交前寫(xiě)到磁盤(pán)。只要事務(wù)成功提交，數(shù)據(jù)必然已經(jīng)持久化。
  C. Undo log必須先于數(shù)據(jù)持久化到磁盤(pán)。如果在G,H之間系統(tǒng)崩潰，undo log是完整的，
     可以用來(lái)回滾事務(wù)。
  D. 如果在A-F之間系統(tǒng)崩潰,因?yàn)閿?shù)據(jù)沒(méi)有持久化到磁盤(pán)。所以磁盤(pán)上的數(shù)據(jù)還是保持在事務(wù)開(kāi)始前的狀態(tài)。

缺陷：每個(gè)事務(wù)提交前將數(shù)據(jù)和Undo Log寫(xiě)入磁盤(pán)，這樣會(huì)導(dǎo)致大量的磁盤(pán)IO，因此性能很低。

如果能夠?qū)?shù)據(jù)緩存一段時(shí)間，就能減少I(mǎi)O提高性能。但是這樣就會(huì)喪失事務(wù)的持久性。因此引入了另外一
種機(jī)制來(lái)實(shí)現(xiàn)持久化，即Redo Log.

01 – Redo Log

- 原理
  和Undo Log相反，Redo Log記錄的是新數(shù)據(jù)的備份。在事務(wù)提交前，只要將Redo Log持久化即可，
  不需要將數(shù)據(jù)持久化。當(dāng)系統(tǒng)崩潰時(shí)，雖然數(shù)據(jù)沒(méi)有持久化，但是Redo Log已經(jīng)持久化。系統(tǒng)可以根據(jù)
  Redo Log的內(nèi)容，將所有數(shù)據(jù)恢復(fù)到最新的狀態(tài)。

- Undo + Redo事務(wù)的簡(jiǎn)化過(guò)程
  假設(shè)有A、B兩個(gè)數(shù)據(jù)，值分別為1,2.
  A.事務(wù)開(kāi)始.
  B.記錄A=1到undo log.
  C.修改A=3.
  D.記錄A=3到redo log.
  E.記錄B=2到undo log.
  F.修改B=4.
  G.記錄B=4到redo log.
  H.將redo log寫(xiě)入磁盤(pán)。
  I.事務(wù)提交

- Undo + Redo事務(wù)的特點(diǎn)
  A. 為了保證持久性，必須在事務(wù)提交前將Redo Log持久化。
  B. 數(shù)據(jù)不需要在事務(wù)提交前寫(xiě)入磁盤(pán)，而是緩存在內(nèi)存中。
  C. Redo Log 保證事務(wù)的持久性。
  D. Undo Log 保證事務(wù)的原子性。
  E. 有一個(gè)隱含的特點(diǎn)，數(shù)據(jù)必須要晚于redo log寫(xiě)入持久存儲(chǔ)。

- IO性能
  Undo + Redo的設(shè)計(jì)主要考慮的是提升IO性能。雖說(shuō)通過(guò)緩存數(shù)據(jù)，減少了寫(xiě)數(shù)據(jù)的IO.
  但是卻引入了新的IO，即寫(xiě)Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。
  為了保證Redo Log能夠有比較好的IO性能，InnoDB 的 Redo Log的設(shè)計(jì)有以下幾個(gè)特點(diǎn)：

  A. 盡量保持Redo Log存儲(chǔ)在一段連續(xù)的空間上。因此在系統(tǒng)第一次啟動(dòng)時(shí)就會(huì)將日志文件的空間完全分配。
     以順序追加的方式記錄Redo Log,通過(guò)順序IO來(lái)改善性能。
  B. 批量寫(xiě)入日志。日志并不是直接寫(xiě)入文件，而是先寫(xiě)入redo log buffer.當(dāng)需要將日志刷新到磁盤(pán)時(shí)
     (如事務(wù)提交),將許多日志一起寫(xiě)入磁盤(pán).
  C. 并發(fā)的事務(wù)共享Redo Log的存儲(chǔ)空間，它們的Redo Log按語(yǔ)句的執(zhí)行順序，依次交替的記錄在一起，
     以減少日志占用的空間。例如,Redo Log中的記錄內(nèi)容可能是這樣的：
     記錄1:
     記錄2:
     記錄3:
     記錄4:
     記錄5:
  D. 因?yàn)镃的原因,當(dāng)一個(gè)事務(wù)將Redo Log寫(xiě)入磁盤(pán)時(shí)，也會(huì)將其他未提交的事務(wù)的日志寫(xiě)入磁盤(pán)。
  E. Redo Log上只進(jìn)行順序追加的操作，當(dāng)一個(gè)事務(wù)需要回滾時(shí)，它的Redo Log記錄也不會(huì)從
     Redo Log中刪除掉。

02 – 恢復(fù)(Recovery)

- 恢復(fù)策略
  前面說(shuō)到未提交的事務(wù)和回滾了的事務(wù)也會(huì)記錄Redo Log，因此在進(jìn)行恢復(fù)時(shí),這些事務(wù)要進(jìn)行特殊的
  的處理.有2中不同的恢復(fù)策略：

  A. 進(jìn)行恢復(fù)時(shí)，只重做已經(jīng)提交了的事務(wù)。
  B. 進(jìn)行恢復(fù)時(shí)，重做所有事務(wù)包括未提交的事務(wù)和回滾了的事務(wù)。然后通過(guò)Undo Log回滾那些
     未提交的事務(wù)。

- InnoDB存儲(chǔ)引擎的恢復(fù)機(jī)制
  MySQL數(shù)據(jù)庫(kù)InnoDB存儲(chǔ)引擎使用了B策略, InnoDB存儲(chǔ)引擎中的恢復(fù)機(jī)制有幾個(gè)特點(diǎn)：

  A. 在重做Redo Log時(shí)，并不關(guān)心事務(wù)性。 恢復(fù)時(shí)，沒(méi)有BEGIN，也沒(méi)有COMMIT,ROLLBACK的行為。
     也不關(guān)心每個(gè)日志是哪個(gè)事務(wù)的。盡管事務(wù)ID等事務(wù)相關(guān)的內(nèi)容會(huì)記入Redo Log，這些內(nèi)容只是被當(dāng)作
     要操作的數(shù)據(jù)的一部分。
  B. 使用B策略就必須要將Undo Log持久化，而且必須要在寫(xiě)Redo Log之前將對(duì)應(yīng)的Undo Log寫(xiě)入磁盤(pán)。
     Undo和Redo Log的這種關(guān)聯(lián)，使得持久化變得復(fù)雜起來(lái)。為了降低復(fù)雜度，InnoDB將Undo Log看作
     數(shù)據(jù)，因此記錄Undo Log的操作也會(huì)記錄到redo log中。這樣undo log就可以象數(shù)據(jù)一樣緩存起來(lái)，
     而不用在redo log之前寫(xiě)入磁盤(pán)了。
     包含Undo Log操作的Redo Log，看起來(lái)是這樣的：
     記錄1: Undo log insert >
     記錄2:
     記錄3: Undo log insert >
     記錄4:
     記錄5: Undo log insert >
     記錄6:
  C. 到這里，還有一個(gè)問(wèn)題沒(méi)有弄清楚。既然Redo沒(méi)有事務(wù)性，那豈不是會(huì)重新執(zhí)行被回滾了的事務(wù)？
     確實(shí)是這樣。同時(shí)Innodb也會(huì)將事務(wù)回滾時(shí)的操作也記錄到redo log中。回滾操作本質(zhì)上也是
     對(duì)數(shù)據(jù)進(jìn)行修改，因此回滾時(shí)對(duì)數(shù)據(jù)的操作也會(huì)記錄到Redo Log中。
     一個(gè)回滾了的事務(wù)的Redo Log，看起來(lái)是這樣的：
     記錄1: >
     記錄2: insert A…>
     記錄3: >
     記錄4: update B…>
     記錄5: >
     記錄6: delete C…>
     記錄7: insert C>
     記錄8: update B to old value>
     記錄9: delete A>
     一個(gè)被回滾了的事務(wù)在恢復(fù)時(shí)的操作就是先redo再u(mài)ndo，因此不會(huì)破壞數(shù)據(jù)的一致性.

- InnoDB存儲(chǔ)引擎中相關(guān)的函數(shù)
  Redo: recv_recovery_from_checkpoint_start()
  Undo: recv_recovery_rollback_active()
  Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()

關(guān)于“mysql中undo log 及 redo log是什么”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。