前言
這兩事務日誌用來保證事務原子性、持久性的，undo log(回滾日誌)提供回滾操作，保證原子性，redo log(重做日誌)提供前滾操作，保證持久性。
先聊聊undo log
什麼時候會用到undo log回滾？
- 用戶調用ROLLBACK主動回滾
- 事務出錯
- 輔助redo log實現事務持久性
undo log如何保證原子性？
數據修改前，undo log會備份保存修改前的數據記錄，然後把undo log寫磁盤，數據修改並寫磁盤，然後事務提交。如下有A=1、B=2兩數據
A.事務開始.
B.記錄A=1到undo log.
C.修改A=3.
D.記錄B=2到undo log.
E.修改B=4.
F.將undo log寫到磁盤。
G.將數據寫到磁盤。
H.事務提交
所謂的原子性是事務中系列操作要麼都執行成功，要麼都失敗回滾。看上面這個過程，如果G、H間系統出現故障，根據磁盤中undo log回滾到原始狀態；如果A-F間出現故障 ，因爲數據還沒有更新持久化到磁盤，自然是原始狀態。（這裏面也有隱含的持久性意思）
缺點？
數據和undo log都會寫磁盤，無疑增加了磁盤I/O次數，降低了性能。
再聊聊redo log
上文的undo log隱含中有實現持久性的意思，但是就是因爲增加了大量磁盤I/O會降低性能，所以引入了redo log。redo log記錄數據修改後新數據的備份、冗雜的undo log、未提交的事務和回滾的事務，數據緩存到內存中，只是在事務提交前將redo log持久化到磁盤
如何使用undo log+redo log來保證持久性？
所謂持久化，即事務一旦提交,那麼數據一定會被寫入到數據庫中並持久存儲起來，事務也無法回滾
A.事務開始.
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寫入磁盤。
I.事務提交
記錄undo日誌，修改數據，記錄redo log，持久化redo log，事務提交。
redo log先於數據持久化，數據不會在事務提交前寫磁盤而是緩存起來。
如果發生錯誤，數據庫系統在重啓時會加載redo log找出未被更新到數據庫磁盤中的日誌重新執行以滿足事務的持久性（即對所有已提交的事務重做）
缺點?
雖然免去了數據寫磁盤的IO，但是又增加了redo log的磁盤開銷。
InnoDB爲了解決redo log磁盤開銷的問題提出了以下幾點：
- 儘量保證redo log存儲在連續的一段磁盤空間上，順序的追加方式記錄redo log
- redo log分爲兩部分——redo log緩衝區和磁盤上的redo log文件，所以redo log並不是直接寫入文件，而是先寫入redo log buffer。當需要將日誌刷新到磁盤時(如事務提交),將許多日誌一起寫入磁盤
如圖，根據update操作從磁盤上數據庫中讀取數據到內存，寫如redo日誌緩存，批量寫到redo log文件，事務提交，數據寫回數據庫持久化保存。圖片引自：https://img.draveness.me/2019-02-21-Redo-Logging.jpg
- Redo Log上只進行順序追加的操作，當一個事務需要回滾時，它的Redo Log記錄也不會從Redo Log中刪除掉
- 併發的事務共享Redo Log的存儲空間，它們的Redo Log按語句的執行順序，依次交替的記錄在一起，以減少日誌佔用的空間
如何利用undo log和redo log異常恢復？
今天看到說是有兩種策略，之前以爲就一種。因爲redo log會保存未提交的事務和回滾的事務，所以有：
- 策略一：根據redo log只重做已提交的事務
- 策略二：根據redo log重做包含未提交和回滾在內的事務，再根據undo log回滾那些未提交的事務
- InnoDB採用這種策略
- 該策略必須將undo log優先於redo log持久化到磁盤，但InnoDB爲了降低複雜度把undo log看作數據寫入記錄在redo log中緩存起來，就免去了undo log的磁盤IO
而且不管數據庫上次是正常關閉還是異常關閉，總是會進行恢復操作
參考文章
還有幾篇文章可以看看
版權聲明：本文爲博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/lzw2016/article/details/89420391