mysql存不存在事務提交了一半就斷電了也沒來的及回滾的情況？

1樓：阿丸

這是經典的資料庫事務ACID特性中的永續性和一致性的問題。

簡單來說，事務提交前，會將 redo log 的寫入拆成了兩個步驟，prepare 和 commit，這就是"兩階段提交」。

為什麼要採用兩階段提交呢？

實際上，兩階段提交是分布式系統常用的機制。MySQL使用了兩階段提交後，也是為了保證事務的永續性。Redo log 和bingo 有乙個共同的資料字段，叫 XID,崩潰恢復的時候，會按順序掃瞄 redo log。

假設在寫入binlog前系統崩潰，那麼資料庫恢復後順序掃瞄 redo log，碰到只有 parepare、而沒有 commit 的 redo log，就拿著 XID 去 binlog 找對應的事務，而且binlog也沒寫入，所以事務就直接回滾了。

假設在寫入binlog之後，事務提交前資料庫崩潰，那麼資料庫恢復後順序掃瞄 redo log，碰到既有 prepare、又有 commit 的 redo log，就直接提交，保證資料不丟失。

阿丸：跟面試官侃半小時MySQL事務，說完原子性、一致性、永續性的實現

2樓：

原答案2020.09.14寫的，如下：

嗯嗯，所以重啟時，才會先做crash recovery的嘛。

眾所周知，MySQL事務提交分為三個過程：

① InnoDB）prepare redo log

② Server）write binlog

③ InnoDB）commit redo log

重啟後呢，就看這個事務是在哪個階段掛掉的。

crash recovery時，可能會出現四種狀態：

1）如果在做①的時候掛掉，直接回滾。

2）如果①好了，做②的時候掛掉：

此時redo中是prepare狀態，binlog中沒有該事務的event，則需要回滾。

3）如果②好了，做③的時候掛掉：

此時redo中是prepare狀態，binlog中有該事務的event，則需要提交。

4）如果③也好了，也就是在引擎層已經commit了：

啥都不用做，不需要處理

恢復的大致過程是咋樣的？

這個過程是乙個內部XA recover的過程。

其實就是先檢查binlog（檢查最後乙個即可），將xid拿出來做乙個hash table。

然後檢查redo log，照著checkpoint往後面掃，產生乙個xid list，去上面的hash table裡比對，

如果有的話，就說明前倆步驟沒問題，並告訴innodb提交這些xid對應的事務，沒得的話就回滾，完事。

額外問題，為啥只要檢查最後乙個binlog？此處我白嫖一下某寶核心月報的內容，如下：

因為在每次rotate到乙個新的binlog檔案之前，總是要保證前乙個binlog檔案中對應的事務都提交並且sync redo到磁碟了，也就是說，前乙個binlog檔案中的事務在崩潰恢復時肯定是處於提交狀態的。

【2020.10.13】

更新一下，好像崩潰恢復流程改過了（？）。今天翻了一下丁奇老師45講，描述過程如下：

如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；

如果碰到只有 parepare、而沒有 commit 的 redo log，就拿著 XID 去 binlog 找對應的事務。

看起來丁奇老師的意思是——先掃redo log，再拿著做了一部分的xid去binlog中找。

這樣看起來快一些？可能是MySQL某個版本的feature。

有空好好複習一下。

3樓：

在一般情況下事務有自己一套回滾機制,該重做的重做，該回滾的回滾.能正常啟動,但是突然斷電可能導致資料頁物理層面的損壞導致MYSQL BUG無法啟動.所以要盡量避免這種情況,採用原子寫特性的SSD或者DOUBLE WRITE

4樓：陳廣勝

資料庫故障重啟後，會恢復到乙個和崩潰的瞬間一致的狀態。所以，不存在事務未提交，但事務的髒資料已經寫到資料庫卻無法回滾的情形。參考我在另乙個問題的回答。

MySQL：資料庫宕機以後恢復的過程？如何保證事務的ACID特性？