共計 1773 個字符，預計需要花費 5 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關 MySQL 中的數據編輯過程中涉及的兩階段提交分別是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

MySQL 數據庫中的兩階段提交，不知道您知道不? 這就簡單的聊一聊 MySQL   數據庫中的兩階段提交，兩階段提交發生在數據變更期間(更新、刪除、新增等)，兩階段提交過程中涉及到了 MySQL 數據庫中的兩個日志系統：redo 日志和  binlog 文件。

redo 日志前面已經介紹過了，就不再介紹了，簡單的聊一聊 binlog 文件，binlog 是 MySQL server   層提供的二進制文件，因此所有的存儲引擎都可以使用 binlog 功能，binlog   是追加寫的邏輯日志，記錄了執行語句的原始邏輯，文件寫到指定大小后會切換到下一個文件繼續寫，并不會覆蓋以前寫過的日志文件。

binlog 日志文件主要用于數據恢復和集群環境下各服務器之間的數據同步，在工作中，我們誤刪了數據或者表之類，如果需要恢復的話都是利用 binlog   日志來恢復的，所以 binlog 日志是 MySQL 數據庫中比較重要的模塊。

知道這兩個日志之后，我們把重點回到 MySQL   數據庫兩階段提交，前面我們說了兩階段提交發生在數據變更期間，為了更好的理解兩階段提交，我們用一條更新命令來加以說明，更新語句如下：

mysql  update T set c=c+1 where id=2;

假設未更新前 id=2 的這行數據 c 的值為 0，這條更新語句在 MySQL 數據庫內部是如何執行的呢? 在下面這張執行流程圖：

update 語句執行流程

從流程圖中可以看出，在 InnoDB 存儲引擎下，一條 update 語句在 MySQL 內部執行大概會經歷下面五個步驟：

1、執行器先找引擎取 id=2 這一行數據，如果 ID=2   這一行所在的數據頁本來就在內存中，就直接返回給執行器; 否則，需要先從磁盤讀入內存，然后再返回。

2、執行器拿到引擎給的行數據，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的一行數據，再調用引擎接口寫入這行新數據。

3、引擎將這行新數據更新到內存中，同時將這個更新操作記錄到 redo log 里面，此時 redo log 處于 prepare   狀態。然后告知執行器執行完成了，隨時可以提交事務。

4、執行器生成這個操作的 binlog，并把 binlog 寫入磁盤。

5、執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交 (commit) 狀態，更新完成。

在這五步中，注意用紅顏色標出來的部分，redo 日志被分割成 prepare 和 commit 兩個階段提交，這個過程稱為兩階段提交，不將 redo   日志拆分成兩步提交行不行?

我們可以用反推法來證明，假設不使用兩階段提交，那么就有兩種情況，一種是先提交 redo 日志再提交 binlog 日志，另一種是先提交 binlog   日志再提交 redo 日志，一起來看看這兩種提交方式有什么問題?

先寫 redo log 后寫 binlog。假設在 redo log 寫完，binlog 還沒有寫完的時候，MySQL   進程異常重啟。在這個過程中更新發生了異常，redo 日志是可以在數據庫發生異常是保證數據的持久性，啟動后經過 redo 日志數據恢復后 c 的值是 1，但是  binlog 并沒有寫完，所以在 binlog 日志文件中并沒有記錄這條更新語句，如果用這個 binlog 日志文件來恢復臨時庫的話，恢復出來 id =2   的這行數據的 c 的值為 0，與原庫的值就不一致了。

先寫 binlog 后寫 redo log。如果在 binlog 寫完，redo 日志還沒寫，系統崩潰，系統重啟后，id=2 的這行數據的 c   的值還是為 0，但是在 binlog 日志文件中卻記錄了這次更新，如果需要用 binlog 日志文件來恢復臨時庫的話，那么 id=2 的這行數據 c 的值就為  1，這樣與原庫的值就不一致了。

從這兩個假設中，我們可以看出無論先提交那個日志文件都有可能出現數據不一致的現象，日志文件兩階段提交技術就解決了 redo 日志和 binlog   日志文件記錄數據不一致的問題，從而保證了在數據恢復時數據的一致性。

上述就是丸趣 TV 小編為大家分享的 MySQL 中的數據編輯過程中涉及的兩階段提交分別是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。