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

[[313768]]

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

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

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

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

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

update 語句執(zhí)行流程

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

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

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

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

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

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

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

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

先寫 redo log 后寫 binlog。假設在 redo log 寫完，binlog 還沒有寫完的時候，MySQL 進程異常重啟。在這個過程中更新發(fā)生了異常，redo 日志是可以在數據庫發(fā)生異常是保證數據的持久性，啟動后經過 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 日志文件記錄數據不一致的問題，從而保證了在數據恢復時數據的一致性。

以上就是 MySQL 數據編輯中涉及到的兩階段提交，希望這篇文章對您的學習或者工作有所幫助，如果您覺得文章有幫助，歡迎幫忙轉發(fā)，謝謝。