mysql redo undo 簡書_MySQL Redo Undo MVCC

1、undo保證事務的原子性(復原)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復原

缺點：

每次資料庫的修改都必須将資料以同步的方式寫入磁盤

資料寫入磁盤屬于随機IO，性能方面較差

2、undo+redoA、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

不需要實時以同步的方式将資料寫入磁盤，資料可以背景異步寫入磁盤

redo log寫入磁盤是順序IO

undo log也寫入到redo log中

redo 緩存刷盤規則：

事務送出時

當log buffer 中一半的記憶體空間已經被使用時

log checkpoint時

3、check point

check point機制是為了減少執行個體恢複的時間

緩沖池不夠用時，觸發checkpoint，将髒頁刷盤

重做日志不夠用時，重新整理磁盤

刷髒頁的時候不會阻塞，但是期間修改資料的操作的頁也會記錄LSN，恢複時将與redo中的LSN進行比較判斷，避免了重複操作

4、LSN(日志序列号)

代表着重做日志的寫入總量，寫入redo多少，就單調遞增多少

同時也代表着checkpoint的位置

還代表着頁的版本(資料頁上面也有LSN号，通過與redo的LSN比較決定是否需要進行資料恢複)

5、執行個體恢複

commit到commit ok之間(prepare階段)需要先寫binlog(主從)，否則有可能因為binlog寫失敗影響主從

先恢複已送出完成事務——>未commit事務進行復原——>對于prepare(已commit未OK)事務，如果已經寫binlog則送出，否則復原

6、MVCC

解決讀寫間阻塞的問題