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

[[313768]]

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

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

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

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

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

update 語句執(zhí)行流程

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

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

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

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

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

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

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

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

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

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

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

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