日誌系統：一條SQL更新語句是如何執行的

一條查詢語句通常通過鏈接器、分析器、優化器、執行器等模塊，最後到達存儲引擎。
一條更新語句也須要經鏈接器鏈接數據庫、分析器會經過詞法和語法解析知道這是一條更新語句、優化器決定要使用的索引、而後執行器執行負責具體執行，找到這一行，而後更新。

更新語句和查詢語句不同的是，更新流程還涉及兩個重要的日誌模塊，redo log（重作日誌） 和 binlog （歸檔日誌）。

MySQL 寫 redo log 使用的是 WAL （Write-Ahead Logging）先寫日誌再寫磁盤。

一條記錄須要更新的時候，InnoDB 引擎會先把記錄寫到 redo log 裏面，並更新內存，這個更新就完成了，同時，InnoDB 引擎會在適當的時候將操做記錄更新到磁盤裏面。這個更新每每實在系統比較空閒的時候，redo log 寫滿的時候也會更新到磁盤裏面。

Innodb 的 redo log 是固定大小的，從頭開始寫，寫到末尾就又回到開頭循環寫。

redo log 和 binlog 不一樣點
1，redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，全部引擎均可以使用。
2，redo log 是窩裏日誌，記錄的是 「在某個數據頁上作了什麼修改」 ；binlog 是邏輯日誌，記錄的是這個語句的原始邏輯
3，redo log 是循環寫的，空間固定會用完；binlog 是能夠追加寫的。

執行器和 InnoDB 引擎在執行簡單 Update 語句時的內部流程（實例和執行流程圖）

binlog 和 redo log 使用的是兩階段提交

不是用兩階段提交的後果

redo log 用於保證 crash-safe 能力， innodb_fiush_log_at_trx_commit 這個參數設置成 1 的時候，表示每次事務的 redo log 都直接持久化到硬盤，這個值設置成 1 ，能夠保證 MySQL 異常重啓以後數據不丟失

sync_binlog 這個參數設置成 1 的時候，表示每次事務 binlog 都持久化到硬盤，能夠保證 MySQL 異常重啓以後 binlog 不丟失。

兩階段提交是跨系統維持數據邏輯一致性時經常使用的一個方案