MySQL -update語句流程總結

廢話很少說先來張圖解釋

update T set value = value+1 where ID =2
複製代碼

我想可能大部分人看完這圖，思考片刻，接下來的就不須要在繼續看了，可是考慮到部分朋友仍是新手（包括本身）以及後面複習，仍是稍微嘮叨一段。

update過程

首先，上圖中深色背景的表示在執行器中執行，也就是Server層，淺色的是在InnoDB引擎中執行。
因爲不少朋友並非專業的DBA或者對MySQL內部原理並非特別清晰，因此先對redolog和binlog作簡單的介紹。

• redolog

  重作日誌，屬於物理日誌，上面存儲的是數據庫中最終的內容，有固定的大小，能夠循環讀寫，通常設置innodb_flush_log_at_trx_commit爲1，表示commit事務時將redolog上面的數據刷入到磁盤（具體的能夠自行研究redolog file 和redolog buffer）。具備兩個狀態分別是prepare和commit，在MySQL重啓恢復時會根據commit狀態恢復數據。

• binlog

  歸檔日誌，屬於邏輯日誌，上面存儲的是最初的修改邏輯能夠簡單的理解爲sql語句，能夠追加寫，通常設置sync_binlog爲1，表示commit事務時將binlog上面的數據刷入到磁盤進行歸檔。數據恢復和同步都是經過binlog來實現的。

下面以文字的方式再次描述一下update T set value = value+1 where ID =2的過程。

1. 詞法分析器識別出事update語句；
2. 執行器去InnoDB中進行查詢，找到知足ID = 2 的數據；
3. 執行器將value的值加1；
4. 執行器讓InnoDB將剛剛的新值寫入到InnoDB的內存中；
5. InnoDB在redolog中加入一條記錄，並把該記錄的狀態設置爲prepare；
6. 執行器經「update T set value = value+1 where ID =2」 寫入到binlog中；
7. 此時提交事務，將redolog中prepare的的記錄狀態設爲commit，而且將內存中的新數據刷入磁盤。

以上就是比較簡單的過程理解，那麼爲啥要分開寫redolog呢？即傳說中的兩階段提交？這裏再作個簡單的分析。

首先對這種方式的好處作個總結：保證以上全部的過程若是出現MySQL實例奔潰都不會致使事務的丟失或異常。

接下來分析一下這麼作的具體緣由：

1. 若是是第5步以前crash，就是還沒寫任何日誌，那麼事務就不存在，在恢復後從redolog和binlog中都不會有任何的問題；
2. 若是寫完redolog 的prepare出現了crash，那麼恢復時，經過redolog和binlog的對比，會發現只要一個prepare的日誌，那麼會將事務進行回滾，保證redolog和binlog的統一；
3. 若是寫完binlog後出現crash，那麼恢復時，會進行根據binlog日誌對redolog進行補償，對redolog以前prepare的記錄修改成commit狀態，事務獲得保證；
4. 最後commit後crash，redolog和binlog都是正常的。

redolog只出如今InnDB中，並且是循環寫的，不能持久保存，因此暫時不能用redolog來作主從或者數據備份

以上的是總結了不少博客和書上的內容，並非徹底的原創，本身也是在整理，但願你們能指正不對之處。