00 – Undo Log
Undo Log 是爲了實現事務的原子性，在MySQL數據庫InnoDB存儲引擎中，還用Undo
Log來實現多版本併發控制(簡稱：MVCC)。
- 事務的原子性(Atomicity)
事務中的所有操作，要麼全部完成，要麼不做任何操作，不能只做部分操作。如果在執行的過程中發生
了錯誤，要回滾(Rollback)到事務開始前的狀態，就像這個事務從來沒有執行過。
- 原理
Undo Log的原理很簡單，爲了滿足事務的原子性，在操作任何數據之前，首先將數據備份到一個地方
（這個存儲數據備份的地方稱爲Undo Log）。然後進行數據的修改。如果出現了錯誤或者用戶執行了
ROLLBACK語句，系統可以利用Undo Log中的備份將數據恢復到事務開始之前的狀態。
除了可以保證事務的原子性，Undo Log也可以用來輔助完成事務的持久化。
- 事務的持久性(Durability)
事務一旦完成，該事務對數據庫所做的所有修改都會持久的保存到數據庫中。爲了保證持久性，數據庫
系統會將修改後的數據完全的記錄到持久的存儲上。
- 用Undo Log實現原子性和持久化的事務的簡化過程
假設有A、B兩個數據，值分別爲1,2。
A.事務開始.
B.記錄A=1到undo log.
C.修改A=3.
D.記錄B=2到undo log.
E.修改B=4.
F.將undo log寫到磁盤。
G.將數據寫到磁盤。
H.事務提交
這裏有一個隱含的前提條件：‘數據都是先讀到內存中，然後修改內存中的數據，最後將數據寫回磁盤’。
之所以能同時保證原子性和持久化，是因爲以下特點：
A. 更新數據前記錄Undo log。
B. 爲了保證持久性，必須將數據在事務提交前寫到磁盤。只要事務成功提交，數據必然已經持久化。
C. Undo log必須先於數據持久化到磁盤。如果在G,H之間系統崩潰，undo log是完整的，
可以用來回滾事務。
D. 如果在A-F之間系統崩潰,因爲數據沒有持久化到磁盤。所以磁盤上的數據還是保持在事務開始前的狀態。
缺陷：每個事務提交前將數據和Undo Log寫入磁盤，這樣會導致大量的磁盤IO，因此性能很低。
如果能夠將數據緩存一段時間，就能減少IO提高性能。但是這樣就會喪失事務的持久性。因此引入了另外一
種機制來實現持久化，即Redo Log.
01 – Redo Log
- 原理
和Undo Log相反，Redo Log記錄的是新數據的備份。在事務提交前，只要將Redo Log持久化即可，
不需要將數據持久化。當系統崩潰時，雖然數據沒有持久化，但是Redo Log已經持久化。系統可以根據
Redo Log的內容，將所有數據恢復到最新的狀態。
- Undo + Redo事務的簡化過程
假設有A、B兩個數據，值分別爲1,2.
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事務的特點
A. 爲了保證持久性，必須在事務提交前將Redo Log持久化。
B. 數據不需要在事務提交前寫入磁盤，而是緩存在內存中。
C. Redo Log 保證事務的持久性。
D. Undo Log 保證事務的原子性。
E. 有一個隱含的特點，數據必須要晚於redo log寫入持久存儲。
- IO性能
Undo + Redo的設計主要考慮的是提升IO性能。雖說通過緩存數據，減少了寫數據的IO.
但是卻引入了新的IO，即寫Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。
爲了保證Redo Log能夠有比較好的IO性能，InnoDB 的 Redo Log的設計有以下幾個特點：
A. 儘量保持Redo Log存儲在一段連續的空間上。因此在系統第一次啓動時就會將日誌文件的空間完全分配。
以順序追加的方式記錄Redo Log,通過順序IO來改善性能。
B. 批量寫入日誌。日誌並不是直接寫入文件，而是先寫入redo log buffer.當需要將日誌刷新到磁盤時
(如事務提交),將許多日誌一起寫入磁盤.
C. 併發的事務共享Redo Log的存儲空間，它們的Redo Log按語句的執行順序，依次交替的記錄在一起，
以減少日誌佔用的空間。例如,Redo Log中的記錄內容可能是這樣的：
記錄1: <trx1, insert …>
記錄2: <trx2, update …>
記錄3: <trx1, delete …>
記錄4: <trx3, update …>
記錄5: <trx2, insert …>
D. 因爲C的原因,當一個事務將Redo Log寫入磁盤時，也會將其他未提交的事務的日誌寫入磁盤。
E. Redo Log上只進行順序追加的操作，當一個事務需要回滾時，它的Redo Log記錄也不會從
Redo Log中刪除掉。
02 – 恢復(Recovery)
- 恢復策略
前面說到未提交的事務和回滾了的事務也會記錄Redo Log，因此在進行恢復時,這些事務要進行特殊的
的處理.有2中不同的恢復策略：
A. 進行恢復時，只重做已經提交了的事務。
B. 進行恢復時，重做所有事務包括未提交的事務和回滾了的事務。然後通過Undo Log回滾那些
未提交的事務。
- InnoDB存儲引擎的恢復機制
MySQL數據庫InnoDB存儲引擎使用了B策略, InnoDB存儲引擎中的恢復機制有幾個特點：
A. 在重做Redo Log時，並不關心事務性。 恢復時，沒有BEGIN，也沒有COMMIT,ROLLBACK的行爲。
也不關心每個日誌是哪個事務的。儘管事務ID等事務相關的內容會記入Redo Log，這些內容只是被當作
要操作的數據的一部分。
B. 使用B策略就必須要將Undo Log持久化，而且必須要在寫Redo Log之前將對應的Undo Log寫入磁盤。
Undo和Redo Log的這種關聯，使得持久化變得複雜起來。爲了降低複雜度，InnoDB將Undo Log看作
數據，因此記錄Undo Log的操作也會記錄到redo log中。這樣undo log就可以象數據一樣緩存起來，
而不用在redo log之前寫入磁盤了。
包含Undo Log操作的Redo Log，看起來是這樣的：
記錄1: <trx1, Undo log insert <undo_insert …>>
記錄2: <trx1, insert …>
記錄3: <trx2, Undo log insert <undo_update …>>
記錄4: <trx2, update …>
記錄5: <trx3, Undo log insert <undo_delete …>>
記錄6: <trx3, delete …>
C. 到這裏，還有一個問題沒有弄清楚。既然Redo沒有事務性，那豈不是會重新執行被回滾了的事務？
確實是這樣。同時Innodb也會將事務回滾時的操作也記錄到redo log中。回滾操作本質上也是
對數據進行修改，因此回滾時對數據的操作也會記錄到Redo Log中。
一個回滾了的事務的Redo Log，看起來是這樣的：
記錄1: <trx1, Undo log insert <undo_insert …>>
記錄2: <trx1, insert A…>
記錄3: <trx1, Undo log insert <undo_update …>>
記錄4: <trx1, update B…>
記錄5: <trx1, Undo log insert <undo_delete …>>
記錄6: <trx1, delete C…>
記錄7: <trx1, insert C>
記錄8: <trx1, update B to old value>
記錄9: <trx1, delete A>
一個被回滾了的事務在恢復時的操作就是先redo再undo，因此不會破壞數據的一致性.
- InnoDB存儲引擎中相關的函數
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()
總結
redo和undo是兩種不同的innodb事務實現機制，它們都需要用到ib_logfile日誌文件；
redo：是先記錄操作日誌，雖然記錄操作日誌也是應用了緩存（innodb_log_buffer）但是它還是比數據更新之前更新redo日誌到磁盤日誌文件中，數據的更新會在後面的線程刷新操作過程中被更新，redo操作事務提交後只有日誌被持久化數據暫時未被持久化。
undo:undo操作也使用了緩存，只是它在事務提交的時候會同時將數據和日誌更新到磁盤，這步操作就是和redo的主要區別，並且該操作對磁盤IO的消耗非常大，所以undo操作保證了事務的原子性，事務一旦提交數據也被持久化了。