深入理解MYSQL undo redo

請叫我王蜀黍發表於2018-10-19
MySql

undo log保證事務的原子性（回滾）

A、Begin

B、記錄A=1到undo log中

C、修改記錄A=3

D、記錄B=1到undo log中

E、修改記錄B=2

F、寫入undo log到磁碟中

G、寫入資料到磁碟中

H、Commit
複製程式碼

A-E步驟都是在記憶體中完成

A-F之間如果出現問題，由於undo log和資料都未寫入磁碟，所以直接回滾

F之後出現問題，由於undo log已經落盤，可以利用undo log回滾

  • 缺陷：每個事務提交前將資料和Undo Log寫入磁碟，這樣會導致大量的磁碟IO，因此效能很低。

如果能夠將資料快取一段時間，就能減少IO提高效能。但是這樣就會喪失事務的永續性。因此引入了另外一 種機制來實現持久化，即Redo Log.

PS:這裡有一個隱含的前提條件：資料都是先讀到記憶體中，然後修改記憶體中的資料，最後將資料寫回磁碟。

redo log(優化持久化效能)

  • 原理 和Undo Log相反，Redo Log記錄的是新資料的備份。在事務提交前，只要將Redo Log持久化即可， 不需要將資料持久化。當系統崩潰時，雖然資料沒有持久化，但是Redo Log已經持久化。系統可以根據Redo Log的內容，將所有資料恢復到最新的狀態。
A、Begin

B、記錄A=1到undo log中

C、修改記錄A=3

D、記錄修改日誌到redo log中

E、記錄B=1到undo log中

F、修改記錄B=2

G、記錄修改日誌到redo log中

H、將redo log寫入磁碟

I、Commit
複製程式碼
  • Undo + Redo事務的特點 A. 為了保證永續性，必須在事務提交前將Redo Log持久化。 B. 資料不需要在事務提交前寫入磁碟，而是快取在記憶體中。 C. Redo Log保證事務的永續性。 D. Undo Log保證事務的原子性。 E. 有一個隱含的特點，資料必須要晚於redo log寫入持久儲存。

為了保證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中刪除掉。

相關文章