MySQL重做日誌的概念是什麼

在事務的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裡面。對於底層而言，在成功地將操作寫入redo log後，無論事務是成功提交(commit)還是成功回溯(rollback)，都被認為是成功的。

什麼是真正的交易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重做日誌的概念是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！