1.redo log
Innodb專有的log系統，管的是物理日誌，簡單來說就是磁盤裏面那個物理頁中具體哪一個位置所做的修改
2.binlog
我們都知道Mysql分爲客戶端和服務端，引擎三大部分，binlog屬於服務端這一部分，所以它不是某一個引擎特有的，它做的是邏輯記錄，就是sql語句。
3.爲什麼需要binlog？
因爲我們需要數據在必要的時候做回滾，例如今天是2020.4.5，但領導說因爲今天不吉利，要把數據回滾到昨天，這時候我們只需要取出過去某一時刻的數據庫快照，再讀取binlog(從那一刻的binlog開始讀起)，這樣我們就能把數據回滾回去。
4.爲什麼需要redo log？
因爲我們需要更快的速度，我們的每一次操作都會涉及到物理頁的修改，修改意味着要去改磁盤上的東西，如果我們每一次修改都馬上要對應到磁盤上，對性能來說無疑是不友好的，redo log做的事情就是先把這些修改以日誌的形式存儲起來，等系統有空了，或者已近存不下這麼多日誌了，再去把這些修改落地。
5.redo log和binlog的寫入順序。
會現在redo log中寫入一條日誌，並標誌位prepare，然後再提交到binlog，最後再把redo log中這條日誌修改爲commit，這個過程也稱爲二段提交。
6.爲什麼要這樣做？
首先我們先來看看mysql是如何實現從redo log真正落地到磁盤寫入，1.如果這條記錄在redo log中已經是commit了，那麼就會落地，2.如果這條日誌是prepare狀態，那麼就會去查binlog，如果有就落地，沒有就回滾。
有人可能就會問那既然我們恢復數據的時候只用到了binlog，那我們爲什麼還要有redo log？這當然是不對的，首先redo log是作爲一個提高效率的工具，其次因爲redo log是binlog有效的一個前提，我們考慮這樣一個場景，如果只有binlog，那出現的情況只有2種，第一是已經寫入磁盤，再去寫binlog，第二就是先寫binlog，再寫進物理頁，但是這2種場景，如果第一步失敗，第二步成功都會出現髒數據的問題，細想一下就知道，有日誌但沒有寫進物理頁很明顯不行，寫進物理頁但沒日誌如果以後要做數據恢復也不行，所以說innodb出現之前說沒有數據恢復一說的（突然宕機，非正常結束服務）
那如果反過來呢？其實是可以的，但是redo log是有限的，如果超出了存儲大小，redo log就會進行覆蓋（數據結構是一個循環隊列），所以還是需要binlog的。