相關詞語： redo log：日誌模塊（臨時記錄，類似於便簽），InnoDB 引擎特有日誌 WAL（Write-Ahead Logging）：寫入方式 binlog：日誌模塊（歸檔日誌），Server 層的日誌 crash-safe：redo log帶來的好處（MySQL 可以恢復到固定時間內任意一 ...
相關詞語：
redo log：日誌模塊（臨時記錄，類似於便簽），InnoDB 引擎特有日誌
WAL（Write-Ahead Logging）：寫入方式
binlog：日誌模塊（歸檔日誌），Server 層的日誌
crash-safe：redo log帶來的好處（MySQL 可以恢復到固定時間內任意一秒的狀態）
WAL執行過程（redo log日誌的存儲方式）：
write pos 是當前記錄的位置，checkpoint 是當前要擦除的位置，它們之間的是“便簽”上還空著的部分。如果 write pos 追上 checkpoint，表示“粉板”滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把 checkpoint 推進一下。
redo log 與binlog的不同點：
redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎都可以使用。
redo log 是物理日誌，記錄的是“在某個數據頁上做了什麼修改”；binlog 是邏輯日誌，記錄的是這個語句的原始邏輯，比如“給 ID=2 這一行的 c 欄位加 1 ”。
redo log 是迴圈寫的，空間固定會用完；binlog 是可以追加寫入的。“追加寫”是指 binlog 文件寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌。
首先update語句會把查詢語句的流程先走一遍，區別就在與涉及到的兩個日誌模塊：
update T set c=c+1 where ID=2;
1.連接資料庫（連接器工作）
2.清空查詢緩存（查詢緩存工作）--》更新語句會清空更新表的查詢緩存
3.分析詞法和語法（分析器工作）--》得到這是一條更新語句
4.優化器決定使用ID這個索引（優化器工作）--》決定執行方案
5.執行器開始執行（執行器工作）--》找到這一行，進行更新
更新過程中，執行器與引擎的交互：
此處將redo log 的寫入拆成了兩個步驟：prepare 和 commit，這就是"兩階段提交"。
為什麼需要“兩階段提交“呢？
是為了讓兩份日誌之間的邏輯保持一致。
這裡就可以說說crash-safe功能是怎麼實行的了。
crash-safe（例如）：怎樣讓資料庫恢復到半個月內任意一秒的狀態？
binlog 會記錄所有的邏輯操作，並且是採用“追加寫”的形式。如果需要半個月內可以恢復，那麼備份系統中一定會保存最近半個月的所有 binlog，同時系統會定期做整庫備份。這裡的“定期”取決於系統的重要性，可以是一天一備，也可以是一周一備。
當需要恢復到指定的某一秒時，比如某天下午兩點發現中午十二點有一次誤刪表，需要找回數據，那你可以這麼做：
1.找到最近的一次全量備份
2.從這個備份恢復到臨時庫
3.從備份的時間點開始，將備份的 binlog 依次取出來，重放到中午誤刪表之前的那個時刻。
而redo log 和 binlog 是兩個獨立的邏輯，如果不用兩階段提交，要麼就是先寫完 redo log 再寫 binlog，或者採用反過來的順序。我們看看這兩種方式會有什麼問題。
①，先寫 redo log 後寫 binlog。
假設在 redo log 寫完，binlog 還沒有寫完的時候，MySQL 進程異常重啟。由於我們前面說過的，redo log 寫完之後，系統即使崩潰，仍然能夠把數據恢復回來，所以恢復後這一行 c 的值是 1。但是由於 binlog 沒寫完就 crash 了，這時候 binlog 裡面就沒有記錄這個語句。因此，之後備份日誌的時候，存起來的 binlog 裡面就沒有這條語句。然後你會發現，如果需要用這個 binlog 來恢復臨時庫的話，由於這個語句的 binlog 丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行 c 的值就是 0，與原庫的值不同。
②，先寫 binlog 後寫 redo log。
如果在 binlog 寫完之後 crash，由於 redo log 還沒寫，崩潰恢復以後這個事務無效，所以這一行 c 的值是 0。但是 binlog 裡面已經記錄了“把 c 從 0 改成 1”這個日誌。所以，在之後用 binlog 來恢復的時候就多了一個事務出來，恢復出來的這一行 c 的值就是 1，與原庫的值不同。
簡單說，redo log 和 binlog 都可以用於表示事務的提交狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致。
總結：
redo log 用於保證 crash-safe 能力。
nnodb_flush_log_at_trx_commit 這個參數設置成 1 的時候，表示每次事務的 redo log 都直接持久化到磁碟。（可以保證 MySQL 異常重啟之後數據不丟失）
sync_binlog 這個參數設置成 1 的時候，表示每次事務的 binlog 都持久化到磁碟。（可以保證 MySQL 異常重啟之後 binlog 不丟失）
兩階段提交是跨系統維持數據邏輯一致性時常用的一個方案，即使你不做資料庫內核開發，日常開發中也有可能會用到。
【附加問題】
定期全量備份的周期“取決於系統重要性，有的是一天一備，有的是一周一備”。那麼在什麼場景下，一天一備會比一周一備更有優勢呢？或者說，它影響了這個資料庫系統的哪個指標？
【個人理解】
首先我理解的數據備份是為了恢複數據，假如需要恢復的是上周的數據，那麼一周一備份就需要整周全備+需要恢復的數據時間點binlog來恢復，一天一備的話只需要當天的全備+這天某個時間段的binlog來恢復，那麼一天已備份的優勢就在於恢復丟失數據時的工作量。
其次就是數據丟失時的確認時間，天備只需要確認當天的binlog完好無損，而周備需要確認一整周的binlog完好。
