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 寫完之后，就回到 ib_logfile_0 文件開頭繼續寫
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 數據一致