想跟大家聊聊InnoDB 中的鎖定機制，那麼不可避免的要牽涉到MySQL 的日誌系統，binlog、redo log、undo log 等，看到有小夥伴總結的這三個日誌還不錯，趕緊拿來和各位小夥伴分享。
日誌是mysql資料庫的重要組成部分，記錄著資料庫運作期間各種狀態資訊。 mysql日誌主要包括錯誤日誌、查詢日誌、慢查詢日誌、交易日誌、二進位日誌幾大類。
作為開發，我們重點需要關注的是二進位日誌(binlog)和交易日誌(包括redo log和undo log)，本文接下來會詳細介紹這三種日誌。
binlog用於記錄資料庫執行的寫入性操作(不包括查詢)信息，以二進位的形式保存在磁碟中。 binlog是mysql的邏輯日誌，並且由Server層進行記錄，使用任何儲存引擎的mysql資料庫都會記錄 binlog日誌。
邏輯日誌：可以理解為記錄的就是sql語句.
#物理日誌：mysql資料最終是保存在資料頁中的，實體日誌記錄的就是資料頁變更。
binlog是透過追加的方式進行寫入的，可以透過max_binlog_size參數設定每個binlog文件的大小，當檔案大小達到給定值之後，會產生新的檔案來保存日誌。
在實際應用中，binlog的主要使用場景有兩個，分別是主從複製和資料恢復。
主從複製：在Master#端開啟binlog，然後將binlog傳送到各個Slave 端，Slave端重播binlog因此達到主從資料一致。
資料恢復：透過使用mysqlbinlog工具來恢復資料。
對於InnoDB儲存引擎而言，只有在交易提交時才會記錄biglog ，此時記錄還在記憶體中，那麼biglog是什麼時候刷到磁碟中的呢？
mysql透過sync_binlog參數控制biglog的刷盤時機，取值範圍是0-N：
0：不強制要求，由系統自行判斷何時寫入磁碟；
1：每次commit的時候都要將binlog寫入磁碟;
N：每N個事務，才會將binlog寫入磁碟。
從上面可以看出，sync_binlog最安全的是設定是1，這也是MySQL 5.7.7之後版本的預設值。但是設定一個大一些的值可以提升資料庫效能，因此實際情況下也可以將值適當調大，犧牲一定的一致性來獲得更好的效能。
binlog日誌有三種格式，分別為STATMENT、ROW與MIXED。
在MySQL 5.7.7之前，預設的格式是STATEMENT，MySQL 5.7.7之後，預設值是ROW 。日誌格式透過binlog-format指定。
STATMENT：基於SQL 語句的複製( statement-based replication, SBR# )，每一條都會修改資料的sql語句會記錄到binlog 中 。
ROW：基於行的複製(row-based replication, RBR
)，不記錄每個sql語句的上下文訊息，僅需記錄哪一條數據被修改了。 MIXED：基於STATMENT 與 ROW 兩種模式的混合複製(mixed-based replication , MBR )，一般的複製使用STATEMENT# 模式保存 binlog ，對於 STATEMENT 模式無法複製的操作使用
redo log
我們都知道，事務的四大特性裡面有一個是持久性，具體來說就是只要交易提交成功，那麼對資料庫做的修改就被永久保存下來了，不可能因為任何原因再回到原來的狀態。 ######那麼###mysql###是如何保證一致性的呢？ ######簡單的方法是在每次提交事務時，將涉及修改的所有資料頁刷新到磁碟中。但這麼做會有嚴重的效能問題，主要體現在兩個方面：###為什麼需要redo log
因為Innodb是以頁為單位進行磁碟互動的，而一個交易很可能只修改一個資料頁裡面的幾個字節，這時候將完整的資料頁刷到磁碟的話，太浪費資源了！
一個交易可能涉及修改多個資料頁，並且這些資料頁在物理上並不連續，使用隨機IO寫入效能太差！
因此
mysql設計了redo log，具體來說就是只記錄交易對資料頁做了哪些修改，這樣就能完美地解決效能問題了(相對而言文件更小並且是順序IO)。
redo log包含兩個部分：一個是記憶體中的日誌緩衝(redo log buffer)，另一個是磁碟上的日誌檔案(redo logfile)。
mysql每執行一條DML語句，先將記錄寫入redo log buffer，後續某個時間點再一次將多筆操作記錄寫到redo log file。這種先寫日誌，再寫磁碟的技術就是MySQL
裡常說到的WAL(Write-Ahead Logging)技術。
在電腦作業系統中，用戶空間(user space)下的緩衝區資料一般情況下是無法直接寫入磁碟的，中間必須經過作業系統核心空間(kernel space)緩衝區(OS Buffer)。
因此，redo log buffer寫入redo logfile其實是先寫入OS Buffer，然後再透過系統呼叫# fsync()將其刷到redo log file
中，流程如下：
##mysql支持三種將redo log buffer寫入redo log file的時機，可以透過innodb_flush_log_at_trx_commit參數配置，各參數值意義如下：
redo log實際上記錄資料頁的變更，而這種變更記錄是沒必要全部保存，因此redo log實作上採用了大小固定，循環寫入的方式，當寫到結尾時，會回到開頭循環寫日誌。如下圖：
redo log需要刷盤，還有資料頁也需要刷盤，redo log存在的意義主要就是降低對資料頁刷盤的要求** 。
write pos表示redo log目前記錄的LSN(邏輯序號)位置，check point 表示資料頁變更記錄刷盤後對應redo log所處的LSN(邏輯序號)位置。
write pos到check point之間的部分是redo log空著的部分，用來記錄新的記錄；check point到write pos之間是redo log待落盤的資料頁變更記錄。當write pos追上check point時，會先推check point向前移動，空出位置再記錄新的日誌。
innodb的時候，不管上次是正常關閉還是例外關閉，總是會進行復原操作。因為redo log記錄的是資料頁的物理變化，因此恢復的時候速度比邏輯日誌(如binlog)要快很多。
innodb時，首先會檢查磁碟中資料頁的LSN，如果資料頁的LSN小於日誌中的 LSN，則會從checkpoint開始恢復。
checkpoint的刷盤過程，且資料頁的刷盤進度超過了日誌頁的刷盤進度，此時會出現數據頁中記錄的LSN大於日誌中的LSN，這時超出日誌進度的部分將不會重做，因為這本身就表示已經做過的事情，無需再重做。
binlog與redo log的差異可知： binlog日誌只用於歸檔，只依賴binlog是沒有crash-safe能力的。
但只有redo log也不行，因為redo log是InnoDB特有的，且日誌上的記錄落盤後會被覆寫掉。因此需要binlog和redo log二者同時記錄，才能確保當資料庫發生宕機重新啟動時，資料不會遺失。
資料庫事務四大特性中有一個是原子性，具體來說就是原子性是指對資料庫的一系列操作，要麼全部成功，要麼全部失敗，不可能出現部分成功的情況。
實際上，原子性底層就是透過undo log來實現的。 undo log主要記錄了資料的邏輯變化，例如一條INSERT語句，對應一條DELETE的undo log，對於每個UPDATE語句，對應一條相反的UPDATE的undo log，這樣在發生錯誤時，就能回滾到交易之前的資料狀態。
同時，undo log也是MVCC(多重版本並發控制)實現的關鍵。
以上是MySQL中binlog/redolog/undolog差別是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
