與不同引擎的關係 核心作用 生命週期   日誌型別
undo log 屬於innodb引擎獨有 回滾，保證事務的“原子性”，事務日誌  事務開始前，以類似“快照”的方式記錄現場  邏輯日誌
redo log 屬於innodb引擎獨有 重做，保證事務的“永續性”，事務日誌  事務開始後記錄，prepare階段落盤  物理日誌
binlog 工作在mysql的Server層，與使用哪種引擎無關 實現主從節點資料的複製  事務執行期間記錄，commit階段完成前落盤  邏輯日誌

　　

　　物理日誌：記錄的是"在某個資料頁上做了什麼修改"
　　邏輯日誌：記錄的是這個語句的原始邏輯，也就是sql語句，比如"給ID=2這一行的c欄位加1 "

【undo log】

　　事務開始之前，將當前事務版本生成 undo log（Tips：undo log 也會產生 redo log 來保證 undo log 的可靠性）。

　　事務提交之後，undo log 並不能立馬被刪除，而是放入待清理的連結串列，由 purge 執行緒判斷是否有其它事務在使用 undo 段中表的上一個事務之前的版本資訊，從而決定是否可以清理 undo log 的日誌空間。

　　資料庫事務四大特性中有一個是 原子性 ，具體來說就是 原子性是指對資料庫的一系列操作，要麼全部成功，要麼全部失敗，不可能出現部分成功的情況。

　　實際上， 原子性 底層就是通過undo log實現的。undo log主要記錄了資料的邏輯變化，比如一條INSERT語句，對應一條DELETE的undo log，對於每個UPDATE語句，對應一條相反的UPDATE的undo log，這樣在發生錯誤時，就能回滾到事務之前的資料狀態。例如，user表中原記錄如下：

id name
1 xiaoming

　　執行sql  update user set name = 'xiaohong' where id = 1; 的時候生成的undo log大概是update user set name = 'xiaoming' where id = 1;

　　同時，undo log也是MVCC(多版本併發控制)實現的關鍵。

【redo log】

　　mysql是如何保證事務的永續性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的資料頁全部重新整理到磁碟中。但是這麼做會有嚴重的效能問題，主要體現在兩個方面：

    1. 因為Innodb是以頁為單位進行磁碟互動的，而一個事務很可能只修改一個數據頁裡面的幾個位元組，這個時候將完整的資料頁刷到磁碟的話，太浪費資源了！

    2. 一個事務可能涉及修改多個數據頁，並且這些資料頁在物理上並不連續，使用隨機IO寫入效能太差！

　　因此，mysql設計了redo log機制，並通過WAL（Write-Ahead Logging）技術進行了效能優化。WAL的核心就是先順序IO寫日誌磁碟、再隨機IO寫資料磁碟，節省的是隨機寫磁碟的 IO 消耗。mysql 每執行一條 DML 語句，先將記錄順序追加寫入 redo log buffer並更新記憶體中的資料，等到有空閒執行緒、記憶體不足、Redo Log滿時再批量落盤持久化。

【binlog】

　　binlog是mysql的邏輯日誌並且由Server層進行記錄，記錄物件為任意資料庫引擎的寫入性操作(不包括查詢)資訊，以二進位制的形式儲存在磁碟中。

　　在實際應用中，binlog的主要使用場景有兩個，分別是 主從複製 和 資料恢復 。

    1. 主從複製 ：在Master端開啟binlog，然後將binlog傳送到各個Slave端，Slave端重放binlog從而達到主從資料一致。

    2. 資料恢復 ：通過使用mysqlbinlog工具來恢復資料。

　　資料更新過程中，萬一更新資料的過程中系統出現故障異常重啟了，如何保證事務的永續性、原子性呢？概述如下：

    1. 記錄此次更新前資料記錄的快照現場（即寫undo log）
    2. 讀取此次更新所需要的資料入記憶體
    3. 在記憶體中更新資料（效率高）
    4. 寫redo log，並置redo log狀態為prepare
    5. 寫binlog
    6. 置redo log狀態為commit　

　　　　　　

　　　　　　基於上述簡化版的undo log、redo log和binlog的寫入流程，我們來梳理下原子性、永續性、一致性的可靠性保證：

　　　　　　　　A）假如是在步驟1/2/3中任一步驟發生故障，故障恢復後發現redo log中並無未完成的記錄，故障恢復後只需要回滾undo log恢復現場即可；

　　　　　　　　B）假如在步驟4/5中任一步驟發生故障，故障恢復後發現redo log處於prepare狀態，則進一步判斷是否已經寫入binlog：

        1. 若已經寫入binlog，則重新執行redo log的相關記錄直到成功達到commit狀態（主從的一致性）；
        2. 若未寫入binlog，則回滾undo log恢復現場（原子性）；　　　　　　　

　　　　　　　　C）假如在步驟6發生故障，故障恢復後發現redo log處於commit狀態，表示過程全部正常完成，則什麼都不需要做。