一條SQL查詢語句的執行：聯結器（連線資料庫）、查詢快取（在資料更新的時候會降低效率，已經不用了）、分析器（做什麼）、優化器（怎麼做更好）、執行器。

慢查詢日誌有一個rows_examined欄位，表示這個語句在執行過程中掃描了多少行，這個值即使在執行器每次呼叫引擎獲取資料行的時候累加的。

上述都屬於server層，還有儲存引擎層，是負責儲存資料，提供讀寫介面。

一條SQL更新語句的執行：聯結器、分析器（知道是更新語句）、優化器（知道ID索引）、執行器（找到行更新）

此外，更新流程還涉及兩個重要的日誌模組：redo log重做日誌、bin log歸檔日誌。

（1）物理日誌redo log：如果有人要賒賬，老闆要有黑板和賬本一起配合才能加快效率。

如果只有賬本，人家要賒賬，就要找到賬本記錄，計算，再寫結果，賣的時候很麻煩。還是先在黑板寫比較方便。

黑板和賬本的配合就是WAL，即write-ahead-logging技術，就是先寫日誌，再寫磁碟。

需要更新的時候，InnoDB引擎就先把記錄寫到redo log（黑板）上，並更新記憶體（大腦意念），這個時候更新完成。然後InnoDB引擎在適當的空閒的時候將操作記錄更新到磁盤裡面（賬本）。

redo log是固定大小的，就像黑板寫滿了，老闆就要放下手中的活，更新賬本，擦掉黑板，騰出空間。

write pos是當前記錄的位置，checkpoint是當前擦除的位置。二者之間是黑板空著的位置，記錄操作，如果write pos追上checkpoint，說明黑板滿了，這時候不能執行更新，得停下來擦掉記錄，推進checkpoint。

有了redo log，InnoDB就可以保證即使資料庫發生異常重啟，之前提交得記錄都不會丟失，這個能力叫做crash-safe。

比如老闆忘記記錄，但是黑板有，停業幾天依舊可以記錄。

redo log用於保證crash-safe的能力。innodb_flush_log_at_trx_commit這個引數設定成1的時候，表示每次事務的redo log都直接持久化到磁碟，這樣可以保證MySQL異常重啟之後資料不丟失。

（2）邏輯日誌binlog：（最開始沒有InnoDB引擎，只實現binlog無法實現crash-safe功能）

redo log是InnoDB引擎特有的日誌，而server層也有自己的日誌，叫做binlog即歸檔日誌。

redo log是物理日誌，記錄在某個資料頁做什麼修改；bin log是邏輯日誌，記錄這個語句的原始邏輯。

redo log是迴圈寫的，空間固定會用完；bin log是可以追加寫入的，不會覆蓋以前的日誌。

redo log的寫入分成兩個步驟：prepare和commit，這就是兩階段提交。為了讓兩份日誌之間的邏輯保持一致。（反證法）

binlog有sync_binlog引數，設定成1的時候，表示每次事務的binlog都持久化到磁碟，可以保證MySQL異常重啟之後binlog不丟失。