一、redo log
重做日志
作用：確保事務的持久性。防止在發生故障的時間點，尚有臟頁未寫入磁盤，在重啟mysql服務的時候，根據redo log進行重做，從而達到事務的持久性這一特性。
內容：物理格式的日志，記錄的是物理數據頁面的修改的信息，其redo log是順序寫入redo log file的物理文件中去的。
二、bin log
歸檔日志（二進制日志）
作用：用於復制，在主從復制中，從庫利用主庫上的binlog進行重播，實現主從同步。
用於數據庫的基於時間點的還原。
內容：邏輯格式的日志，可以簡單認為就是執行過的事務中的sql語句。
但又不完全是sql語句這么簡單，而是包括了執行的sql語句（增刪改）反向的信息，也就意味着delete對應着delete本身和其反向的insert；update對應着update執行前后的版本的信息；insert對應着delete和insert本身的信息。
binlog 有三種模式：Statement（基於 SQL 語句的復制）、Row（基於行的復制） 以及 Mixed（混合模式）
三、undo log
回滾日志
作用：保存了事務發生之前的數據的一個版本，可以用於回滾，同時可以提供多版本並發控制下的讀（MVCC），也即非鎖定讀
內容：邏輯格式的日志，在執行undo的時候，僅僅是將數據從邏輯上恢復至事務之前的狀態，而不是從物理頁面上操作實現的，這一點是不同於redo log的。
redo log
mysql，如果每次更新操作都要寫進磁盤，然后磁盤要找到對應記錄，然后再更細，整個過程io成本、查找成本都很高。
解決方案：WAL技術（Write-Ahead Logging）。先寫日志，再寫磁盤。
具體來說，當有一條記錄需要更新的時候，InnoDB 引擎就會先把記錄寫到 redo log里面，並更新內存，這個時候更新就算完成了。同時，InnoDB 引擎會在適當的時候，將這個操作記錄更新到磁盤里面，而這個更新往往是在系統比較空閑的時候做。InnoDB 的 redo log 是固定大小的，比如可以配置為一組 4 個文件，每個文件的大小是 1GB，那么總共就可以記錄 4GB 的操作。從頭開始寫，寫到末尾就又回到開頭循環寫，如下面這個圖所示。
write pos 是當前記錄的位置，一邊寫一邊后移，寫到第 3 號文件末尾后就回到 0 號文件開頭。checkpoint 是當前要擦除的位置，也是往后推移並且循環的，擦除記錄前要把記錄更新到數據文件。
write pos 和 checkpoint 之間的是log上還空着的部分，可以用來記錄新的操作。如果 write pos 追上 checkpoint，表示log滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把 checkpoint 推進一下。
有了 redo log，InnoDB 就可以保證即使數據庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為 crash-safe。
bin log
MySQL 整體來看，其實就有兩塊：一塊是 Server 層，它主要做的是 MySQL 功能層面的事情；還有一塊是引擎層，負責存儲相關的具體事宜。redo log 是 InnoDB 引擎特有的日志，而 Server 層也有自己的日志，稱為 binlog（歸檔日志）。
這兩種日志有以下三點不同。
1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎都可以使用。
2. redo log 是物理日志，記錄的是“在某個數據頁上做了什么修改”；binlog 是邏輯日志，記錄的是這個語句的原始邏輯，比如“給 ID=2 這一行的 c 字段加 1 ”。
3. redo log 是循環寫的，空間固定會用完；binlog 是可以追加寫入的。“追加寫”是指 binlog 文件寫到一定大小后會切換到下一個，並不會覆蓋以前的日志。
update 語句時的內部流程：
1. 執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜索找到這一行。如果 ID=2 這一行所在的數據頁本來就在內存中，就直接返回給執行器；否則，需要先從磁盤讀入內存，然后再返回。
2. 執行器拿到引擎給的行數據，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的一行數據，再調用引擎接口寫入這行新數據。
3. 引擎將這行新數據更新到內存中，同時將這個更新操作記錄到 redo log 里面，此時 redo log 處於 prepare 狀態。然后告知執行器執行完成了，隨時可以提交事務。
4. 執行器生成這個操作的 binlog，並把 binlog 寫入磁盤。
5. 執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成。
最后三步，將 redo log 的寫入拆成了兩個步驟：prepare 和 commit，這就是"兩階段提交"。
兩階段提交
兩階段提交，是為了binlog和redolog兩分日志之間的邏輯一致。redo log 和 binlog 都可以用於表示事務的提交狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致。
由於 redo log 和 binlog 是兩個獨立的邏輯，如果不用兩階段提交，要么就是先寫完 redo log 再寫 binlog，或者采用反過來的順序。可能造成的問題：
update 語句來做例子。假設當前 ID=2 的行，字段 c 的值是 0，再假設執行 update 語句過程中在寫完第一個日志后，第二個日志還沒有寫完期間發生了 crash，會出現什么情況呢？
1. 先寫 redo log 后寫 binlog。
假設在 redo log 寫完，binlog 還沒有寫完的時候，MySQL 進程異常重啟。由於，redo log 寫完之后，系統即使崩潰，仍然能夠把數據恢復回來，所以恢復后這一行 c 的值是 1。但是由於 binlog 沒寫完就 crash 了，這時候 binlog 里面就沒有記錄這個語句。因此，之后備份日志的時候，存起來的 binlog 里面就沒有這條語句。然后你會發現，如果需要用這個 binlog 來恢復臨時庫的話，由於這個語句的 binlog 丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行 c 的值就是 0，與原庫的值不同。
2. 先寫 binlog 后寫 redo log。
如果在 binlog 寫完之后 crash，由於 redo log 還沒寫，崩潰恢復以后這個事務無效，所以這一行 c 的值是 0。但是 binlog 里面已經記錄了“把 c 從 0 改成 1”這個日志。所以，在之后用 binlog 來恢復的時候就多了一個事務出來，恢復出來的這一行 c 的值就是 1，與原庫的值不同。
如果不使用“兩階段提交”，那么數據庫的狀態就有可能和用它的日志恢復出來的庫的狀態不一致。
擴容的時候，也就是需要再多搭建一些備庫來增加系統的讀能力的時候，現在常見的做法也是用全量備份加上應用 binlog 來實現的，這個“不一致”就會導致線上出現主從數據庫不一致的情況。
undo log
undo用來回滾行記錄到某個版本。undo log一般是邏輯日志，根據每行記錄進行記錄。
undo日志用於記錄事務開始前的狀態，用於事務失敗時的回滾操作；redo日志記錄事務執行后的狀態，用來恢復未寫入data file的已成功事務更新的數據。例如某一事務的事務序號為T1，其對數據X進行修改，設X的原值是0，修改后的值為1，那么Undo日志為<T1, X, 0>，Redo日志為<T1, X, 1>。