深入理解MySQL重做紀錄檔 redo log

在事務的ACID特性中，原子性（A）、一致性（C）、永續性（D）由undo log和redo log實現，隔離性（I）由鎖+MVCC實現

undo log：事務還沒有commit，中途執行異常，可以使用undo log把資料恢復到事務執行前的狀態，確保事務的原子性

redo log：事務commit成功，由於更新磁碟資料需要一段時間，此時若發生異常，可以使用redo log重新執行這一事務的SQL，確保事務的永續性（只要事務commit成功，不管發生什麼異常事件，只要下一次MySQL服務正常進行，那上一次commit的資料一定要恢復回來）

一、redo log概念

redo log：被稱為物理紀錄檔，記錄的就是最終修改後的按頁面儲存的資料頁，直接存資料最終的狀態，用於確保事務的永續性

undo log：被稱為邏輯紀錄檔，儲存的是具體的相應的SQL語句。如果現在執行的是insert，回滾的時候就執行delete；如果現在執行的update，就把原來的舊值再update回來

redo log預設放在/var/lib/mysql下

redo log是在事務begin時就開始記錄（並不是事務commit時才記錄，因為整個事務做的操作可能很多，如果在commit的時候才寫redo log，此時一旦發生異常，redo log還沒寫，這就太晚了，無法確保事務的永續性），不管事務是否提交都會記錄下來，在異常發生時（如資料持久化過程中掉電），InnoDB會使用redo log恢復到掉電前的時刻，保證資料的完整性

innodb_log_buffer_size預設是16M，就是redo log緩衝區的大小，它隨著事務開始，就開始寫redo log，如果事務比較大，為了避免事務執行過程中花費過多磁碟IO，可以設定比較大的redo log快取，節省磁碟IO。往磁碟上刷是有重新整理的時機，達到時機就花費磁碟IO，如果buffer比較大，會更慢的達到重新整理的時機，效率更高。

InnoDB修改運算元據，不是直接修改磁碟上的資料，實際只是修改Buffer Pool中的資料。InnoDB總是先把Buffer Pool中的資料改變記錄到redo log中，用來進行崩潰後的資料恢復。 優先記錄redo log，然後再找時機慢慢的將Buffer Pool中的髒資料重新整理到磁碟上。

innodb_log_group_home_dir指定的目錄下的兩個檔案：ib_logfile0，ib_logfile1，該檔案被稱作重做紀錄檔

buffer pool快取池： 可存放索引快取、資料快取等，可加速讀寫，直接運算元據頁，寫redo log修改就算完成，有專門的執行緒去做把buffer pool中的dirty page寫入磁碟

buffer pool預設大小為134M（MySQL 5.7）

大致結構如圖所示：

事務讀取，修改都是優先操作快取池中的資料。在實際專案中，mysqld會單獨的跑在一個機器上，可以分配大量的記憶體專門做InnoDB的buffer pool，加快CRUD

二、快取、磁碟結構

當事務commit的時候，在關係圖上的操作就是把InnoDB Log Buffer的內容寫入磁碟，寫成功的話，在磁碟上的redo log會記錄狀態——commit，如果沒有寫成功或者寫完，則記錄狀態——prepare

log在寫入磁碟的過程中也有可能發生異常，斷電等問題，導致在寫redo log的時候沒有寫完（這相當於事務沒有commit成功），此時MySQL下次在恢復的時候就沒有必要考慮這個事務的完整性，因為狀態並不是commit，都寫入磁碟上才表示redo log寫成功，狀態才變成commit。狀態變成commit後需要維護事務的ACID特性。

是不是commit的時候，buffer poll裡面的髒資料（資料有被修改）才被寫入磁碟？

並不需要等commit的時候才開始。事務可能修改的資料量比較大，而快取容量有限，對於buffer poll快取的資料，會有專門的執行緒在合適的時間，往磁碟上去重新整理，如果出現掉電，下一次MySQL啟動後，會根據redo log裡面記錄的資料，對資料進行恢復。

undo log本身也是記錄在redo log中

undo log支援事務回滾，也不是一瞬間就能完整，最終要修改的也是磁碟上的資料，為防止回滾過程中出現異常，所以undo log要記錄在redo log裡面。事務commit成功或者rollback成功，對於底層，都是成功的把操作寫到redo log裡面。

什麼是真正的事務commit成功？

不是把資料全部刷到磁碟，而是把記錄事務完整操作的redo log從log buffer寫入磁碟，再把被修改資料的狀態置為commit才算是實現了事務commit成功。此時雖然資料還在buffer poll，但只要我們的redo log儲存完整，資料就可以恢復，會有專門的執行緒去負責把buffer poll裡的資料寫入磁碟

事務進行操作的時候，永遠是先寫redo log，然後才是寫buffer pool；事務成功commit，就是要保證redo log完整記錄到磁碟上

至於表資料的更改，buffer pool的髒資料頁是不是重新整理到磁碟上，我們根本不用擔心，只要redo log完整的寫到磁碟上，我們可以隨時通過redo log重做紀錄檔來恢復事務成功commit的資料狀態（資料庫最重要的是紀錄檔，而不是資料）

到此這篇關於深入理解MySQL重做紀錄檔 redo log的文章就介紹到這了,更多相關MySQL redo log內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！