redo log 是InnoDB儲存引擎層的日誌，其他儲存引擎不存在的 bin log是服務層的日誌，不區分儲存引擎

redo log 是物理日誌，記錄的是"在 XXX 頁上做了 XXX 修改"; binlog 是邏輯日誌，比如" 給 id = 2 這一行的 c 欄位加 1"

redo log 是有固定大小的，所以它的空間會用完，如果用完的話，一定要進行一些寫入磁碟的操作才可以繼續; binlog 是可以追加寫入的，也就是 binlog 沒有空間的概念，一直寫就行了

redo log的主要作用

當update等操作附帶的where條件，需要先檢索再更新。如果資料量很大，查詢複雜這樣直接處理再寫到磁碟IO代價很大，

因此可以記錄在redo log 同時更新記憶體，這樣就算update成功了，InnoDB等到合適時機再把資料更新到磁碟。(WAL 技術，也就是 WriteAheadLogging ，核心就是先寫日誌，再寫磁碟)

redo log 不能一直寫吧？如果更新操作一直寫入到 redo log 中的話，不限制大小的話，可能伺服器上的儲存空間都被 redo log 給佔滿了

所以redo log寫一段時間後會寫入磁碟，然後即時清理

所以 InnoDB 的 redo log 是固定大小的，比如我們配置了一組 4 個檔案，每個檔案大小是 1GB ，那麼它的操作可能就會這樣:

主要就是 write pos 和 checkpoint ， write pos 比較好理解，它就是當前記錄的位置，有需要記錄的操作就從當前位置向後移，等把ib_logfile_3

checkpoint 是當前要擦除的位置，就是 InnoDB 引擎不是會在恰當的時候，將這些操作進行持久化，更新到磁碟上去，那持久化之後的資料是不是就可以擦除了

write pos 和 checkpoint 之間的部分就是可以用來記錄操作的部分，那麼如果 write pos 和 checkpoint 相遇了怎麼辦？相遇了是不是說明這個時候分配的 redo log 大小用完了，那這時候就不能再進行更新操作了，必須停下來處理一下，將 checkpoint 往前推推才行

就是因為有了 redo log ，所以 InnoDB 才可以保證即使資料庫發生了異常重啟，也沒關係，之前提交的記錄都還在，只需要根據 redo log 裡面的記錄進行相應恢復就可以了

udpate一條例子

我現在要給id = 2 這一行的 c 欄位加 1，到 MySQL 層面

首先，會先找到這條 id = 2 的資料，然後找到 c 欄位進行加 1 操作，這個時候，引擎會將這行資料更新到記憶體中，同時把這個更新操作記錄到 redo log 裡面，這個時候 redo log 處於 prepare 狀態，隨後執行器生成這個操作的 binlog ，並且把 binlog 寫入到磁碟完成之後，執行器呼叫引擎的提交事務介面，引擎把剛剛寫入的 redo log 從 prepare 狀態改成 commit 狀態，這樣更新操作才算完成

這就是傳說中的的”兩階段提交“，保證了redo log 和 bin log 資料一致