現有一張表，建表語句如下：

mysql> create table T(ID int primary key, c int);

如果要將 ID=2 這一行的a字段值加 1，SQL語句會這么寫：

 mysql> update T set c =c +1 where ID = 2;

上面這條sql執行時，分析器會通過詞法和語法解析得知這是一條更新語句，優化器決定要使用ID這個索引，然后執行器負責具體執行找到這一行然后更新。

與查詢流程不同的是，更新流程會涉及兩個重要的日志模塊: ：redo log（重做日志）和 binlog（歸檔日志）

redo log - 記錄物理日志，為InnoDB 引擎獨有

MySQL 中如果每一次的更新操作都需要寫進磁盤，然后磁盤要找到對應的那條記錄，然后再更新，整個過程 IO 成本、查找成本都很高。為了解決這個問題，MySQL 的設計者就用了類似過去酒店掌柜使用粉板記賬的思路(生意紅火柜臺很忙時，先把賬記到粉板上，待不忙或打烊后再根據粉板和賬本記錄更新賬本)來提升更新效率，這個實現方式其實就是 MySQL 里經常說到的 WAL(Write-Ahead Logging) 技術, 它的關鍵點就是先寫日志，再寫磁盤，也就是先寫粉板，等不忙的時候再寫賬本。

即當有一條記錄需要更新的時候，InnoDB 引擎就會先把記錄寫到 redo log（粉板）里面，并更新內存，這個時候更新就算完成了。

redo log 是固定大小的，比如可以配置為一組 4 個文件，每個文件的大小是 1GB，那么這塊“粉板”總共就可以記錄 4GB 的操作。從頭開始寫，寫到末尾就又回到開頭循環寫，如下面這個圖所示：

write pos 是當前記錄的位置，一邊寫一邊后移，寫到第 3 號文件末尾后就回到 0 號文件開頭。checkpoint 是當前要擦除的位置，也是往后推移并且循環的，擦除記錄前要把記錄更新到數據文件。
write pos 和 checkpoint 之間的是“粉板”上還空著的部分，可以用來記錄新的操作。如果 write pos 追上 checkpoint，表示“粉板”滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把checkpoint 推進一下。 redo log 使MySQL 具備了crash-safe的能力。

binlog（歸檔日志）- Server 層邏輯日志

binlog 日志只能用于歸檔，其是MySQL 的 Server 層實現，所有引擎都可以使用。

redo log 與 binlog 的不同

• redo log 是循環寫的，空間固定會用完；binlog 是可以追加寫入的，“追加寫”是指binlog 文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志。
• redo log 是物理日志，記錄的是“在某個數據頁上做了什么修改”， binlog 記錄的是這個語句的原始邏輯，比如“給 ID=2 這一行的 c 字段加 1 ”

兩階段提交

由于 redo log 和 binlog 是兩個獨立的邏輯，如果不用兩階段提交，要么就是先寫完
redo log 再寫 binlog，或者采用反過來的順序，數據庫的狀態就有可能和用它的日志恢復出來的庫的狀態不一致。

了解完上述知識，回過頭來再看本文前述的更新sql，大體執行流程如下：

1. 執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜索找到這一行。如果ID=2 這一行所在的數據頁本來就在內存中，就直接返回給執行器；否則，需要先從磁盤讀入內存，然后再返回。
2. 執行器拿到引擎給的行數據，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的一行數據，再調用引擎接口寫入這行新數據
3. 引擎將這行新數據更新到內存中，同時將這個更新操作記錄到 redo log 里面，此時redo log 處于 prepare 狀態。然后告知執行器執行完成了，隨時可以提交事務。
4. 執行器生成這個操作的 binlog，并把 binlog 寫入磁盤。
5. 執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成
   執行流程圖如下，圖中淺色框表示是在 InnoDB 內部執行的，深色框表示是在執行器中執行的。
   

參數

innodb_flush_log_at_trx_commit 這個參數設置成1 的時候，表示每次事務的 redo log 都直接持久化到磁盤，這樣可以保證 MySQL 異常重啟之后數據不丟失.

sync_binlog 這個參數設置成 1 的時候，表示每次事務的 binlog 都持久化到磁盤，可以保證 MySQL 異常重啟之后binlog不丟失。