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 資料庫內部是如何執行的呢？在下面這張執行流程圖：

從流程圖中可以看出，在 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 日誌檔案記錄資料不一致的問題，從而保證了在資料恢復時資料的一致性。

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

最後

目前網際網路上很多大佬都有 MySQL 相關文章，如有雷同，請多多包涵了。原創不易，碼字不易，還希望大家多多支援。若文中有所錯誤之處，還望提出，謝謝。

歡迎掃碼關注微信公眾號：「網際網路平頭哥」，和平頭哥一起學習，一起進步。

相關推薦