1.MySQL邏輯架構示意圖
- 對於一條update語句來說，也會執行上圖中的流程，如果您對於上圖中的連接器、分析器等名詞不太熟悉，請查看上一篇文章：MySQL邏輯架構中各名詞詳解
2.一條示例update語句執行過程簡析
# 建表SQL
create table `article` (
`id` bigint(20) unsigned NOT NULL DEFAULT 0,
`commentcnt` int(11) unsigned NOT NULL DEFAULT 0,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
# 插入數據
insert into `article` (`id`, `commentcnt`) values(1, 11);
insert into `article` (`id`, `commentcnt`) values(2, 22);
- 更新數據sql
update `article` set `commentcnt` = `commentcnt` + 1 where `id` = 2;
- 該SQL的執行過程：
- 連接器會先檢查權限，若沒有權限就直接返回錯誤信息，如果有權限就會清除查詢緩存（MySQL 8.0版本之前），將article表所有緩存結果都清空（一般不建議使用查詢緩存）。接下來執行下一步。
- 通過分析器先進行詞法分析，提取sql語句裏面的關鍵字。示例SQL取的update，然後提取要更新的表名article ，更新條件是id= 2 ，然後進行語法分析，判斷sql語句是否正確，如果有錯會返回報錯信息，否則執行下一步。
- 優化器確定執行方案。優化器根據自己的優化算法選擇一個執行效率最好的一個方案。比如：優化器會去找id字段有沒有索引，使用id主鍵索引，執行計劃確定後就會執行下一步。
- 執行器首先會判斷當前用戶對article表是否有更新的權限，如果沒有權限就會返回權限錯誤，若有權限會打開表執行，根據表的引擎定義調用引擎提供的接口，返回引擎執行結果。
與查詢SQL流程不同的是，更新SQL流程還涉及兩個重要的日誌模塊redo log 和 binlog
3. MySQL日誌
3.1 redo log
- 前言：之前MySQL每一條更新記錄，都需要寫入磁盤，然後磁盤也要找到對應的那條記錄，然後再更新，整個過程 IO 成本、查找成本都很高。爲了解決這個問題，MySQL 的設計者就用了WAL技術解決該問題。
- WAL（Write-Ahead Logging）預寫日誌：先寫日誌，再寫磁盤，將隨機寫轉換成了順序寫，大大提升了數據庫的性能。WAL技術的典型應用就是redo log
- redo log的定義：一塊固定大小的重做物理日誌文件，可以循環寫。redo log記錄的是“在某個數據頁上做了什麼修改”，是InnoDB引擎特有的日誌。
- redo log的工作流程：當有一條記錄更新的時候，InnoDB 引擎就會先把記錄寫到 redo log 裏面，並更新內存，這個時候更新就算完成了。同時，InnoDB 會在適當的時候，將這個操作記錄更新到磁盤
- redo log寫示例：比如MySQL配置redo log一組4個1G的文件，寫redo log的流程示意圖如下
![redo log循環寫日誌]()
- write pos：當前記錄的位置，邊寫邊往後移動，直到移動到ib_logfile_3的末尾，然後會回到ib_logfile_0文件的開頭
- checkpoint：當前要擦除的位置，和write pos一樣也是往後移動且會循環，擦除記錄前要把記錄保存到磁盤中
- write pos和checkpoint之前的空間：記錄新的操作，如果write pos追上checkpoint，就表明redo log已經沒有空間來記錄新的操作了，這時就需要把擦除當前記錄保存到磁盤中，從而保證新的操作可以被記錄。
- crash-safe：因爲有redo log，所以InnoDB可以保證即使數據庫發生異常重啓，之前提交的記錄都不會丟失，這個能力稱爲crash-safe
3.2 binlog
- binlog （歸檔日誌）定義：server層日誌，是邏輯日誌，記錄語句的原始邏輯，比如“給ID=2這一行的c字段加1 ”。可以追加寫入，即 binlog 文件寫到一定大小後會切換到下一個binlog文件，並不會覆蓋以前的日誌。
- binlog的三種模式
| 模式 | statement | row | mixed |
|---|---|---|---|
| 定義 | 記錄的是SQL語句 | 記錄行的內容(記兩條, 更新前和更新後都有) | statement和row的結合，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌格式 |
| 優點 | 更新時只需要記錄一條SQL，減少日誌量 | 便於恢復數據 | MySQL自動選擇最優模式 |
| 缺點 | 主從複製時某些函數sleep()或功能不能正確複製，導致出現bug | 數據更新時產生大量文件，特別是alter table語句，全表數據變更 | 表結構變更等需要修改大量數據時使用statement，update或delete操作還是使用row模式記錄 |
- 注：一般採用row模式，因爲遇到時間，從庫可能會出現不一致的情況，但是row更新前後都有
- binlog保證完整性的方法：statement格式的binlog, 最後會有Commit標識。row格式的binlog, 最後會有一個XID event標識，在MySQL5.6.2版本以後, 還引入了binlog-checksum參數, 用來驗證binlog內容的正確性。
3.3 redo log和binlog的區別
- redo是物理日誌，binlog是邏輯日誌
- redo log是InnoDB引擎特有的，binlog是MySQL的Server層實現的，所有引擎都可以使用。
- redo log循環寫，空間固定會用完；binlog可以追加寫入。
3.4 出現兩份日誌的原因
- binlog沒有能力恢復“數據頁”，redo log 來實現 crash-safe 能力。
- redo log是循環寫，寫到末尾是要回到開頭繼續寫的。這樣歷史日誌沒法保留，redo log也就起不到歸檔的作用。binlog 日誌來實現歸檔
- MySQL系統依賴於binlog，例如：MySQL系統高可用的基礎，就是binlog複製。
4. update語句執行過程詳解
update `article` set `commentcnt` = `commentcnt` + 1 where `id` = 2;
- 有了redo log 和 binlog的知識儲備後，再來看看這條update語句的執行原理，
4.1 update語句的執行流程圖
（圖中淺色框表示是在InnoDB內部執行的，深色框表示是在執行器中執行的）
更新SQL執行流程：
- 連接數據庫，清空查詢緩存（MySQL8.0之前），分析詞法和語法後知道這是一條update語句，優化器決定使用ID這個索引
- 執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜索找到這一行。
- 如果 ID=2 這一行所在的數據頁本來就在內存中，就直接返回給執行器，否則，需要先從磁盤讀入內存，然後再返回。
- 執行器拿到引擎給的行數據，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的一行數據，再調用引擎接口寫入這行新數據。
- 引擎將這行新數據更新到內存中，同時將這個更新操作記錄到 redo log 裏面，此時 redo log 處於 prepare 狀態。然後告知執行器執行完成了，隨時可以提交事務。
- 執行器生成這個操作的 binlog，並把 binlog 寫入磁盤。
- 執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成
4.2 兩階段提交
- 定義：更新流程中寫入redo log的過程拆成了兩個步驟prepare和commit。如果不使用兩階段提交，數據庫的狀態就有可能和用它的日誌恢復出來的庫的狀態不一致。
- 作用：讓redo log和binlog邏輯上保持一致. 如果在commit時崩潰了, 雖然沒有commit, 但是prepare和binlog完整, 所以重啓之後會自動commit
- MySQL異常重啓後的崩潰恢復規則:
- 如果redo log裏面的事務是完整的, 也就是有了commit標識, 則直接提交
- 如果redo log裏面的事務只有完整的prepare, 則判斷對應的事務是否存在完整的binlog，如果是, 則提交事務，否則,回滾事務
- redo log和binlog的如何關聯
- 它們有一個共同的數據字段XID. 崩潰恢復的時候, 會按順序掃描redo log
- 如果碰到既有prepare, 又有commit的redo log, 就直接提交
- 如果碰到只有prepare, 而沒有commit的redo log, 就拿着XID去binlog找對應的事務
- 雙1配置保證不丟數據：
- innodb_flush_log_at_trx_commit=1 每次事務的redo log都直接持久化到磁盤。可以保證MySQL異常重啓之後數據不丟失。
- sync_binlog=1 每次事務的binlog都持久化到磁盤。可以保證MySQL異常重啓之後binlog不丟失。