一條update SQL語句是如何執行的

　　一條更新語句的執行過程和查詢語句相似，更新的流程涉及兩個日誌：redo log（重作日誌）和binlog（歸檔日誌）。好比咱們要將ID(主鍵)=2這一行的值加(c：字段)1，SQL語句以下：

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

• redo log

　　重作日誌是InnoDB引擎特有的，是物理日誌，記錄在「某個數據頁上作了什麼修改「。大小是固定，能夠進行配置大小。假如咱們配置一組4個文件，圖中write pos是當前記錄的位置，日後推移而且循環；checkpoint是當前要擦除的位置，移動規律和前者同樣。二者之間的位置能夠記錄新的操做。

  

　　若是write pos 追上checkpoint，就移動checkpoint擦除一些記錄。因此即便數據能夠發生異常重啓，InnoDB也能夠保證以前提交的記錄不會丟，這就是MySQL的crash_safe能力。

• binlog

　　　歸檔日誌是MySQL的server層的實現的，全部引擎均可以使用。binlog記錄的是sql語句的原始邏輯，好比根劇'id'字段查詢全部的信息；相比redo log的循環寫入，binlog是追加寫的，binlog文件寫到必定大小後會切換到下一個，不會覆蓋之前的日誌。

　　Binlog有兩種模式，statement 格式的話是記sql語句， row格式會記錄行的內容，記兩條，更新前和更新後都有。

　文章開頭的更新語句在InnoDB中的執行流程以下：深色表明在執行器中執行的，淺色是在存儲引擎中。

　　最後寫入redolog分爲了prepare和commit兩步，用來保證兩個日誌寫入的一致性，這就是「兩階段提交」。好比咱們執行「update T set status = 1「時：

• 若是寫入redolog成功，但寫binlog失敗，重啓恢復時，數據庫發現沒有commit，那麼事務自己回滾；備份恢復時沒有binlog，數據庫裏的status值不變。

• 若是在commit失敗，重啓恢復時redolog和binlog一致，從新commit；備份恢復時有binlog，直接恢復。

　　總的來講binlog記錄了對數據庫全部的邏輯操做，能夠經過binlog來備份出一份徹底相同的庫；由於redolog是InnoDB引擎特有的，若是使用其餘引擎，那麼就要依賴binlog來記錄操做。

Q：按期全量備份的週期「取決於系統重要性，有的是一天一備，有的是一週一備」。那麼在什麼場景下，一天一備會比一週一備更有優點呢？或者說，它影響了這個數據庫系統的哪一個指標？

A：一天一備，那麼若是須要恢復數據的話，只要保證當天的binlog完整便可；一週一備的話就要保證一週的binlog完整；同時頻繁全量備份須要更多存儲空間，如何選擇取決於業務的重要性，對應的指標是RTO(目標恢復時間)。

 -- 《MySQL實戰45講》筆記二