針對突然宕機的問題

不會自動繼續執行，不會自動直接回滾，但是可以人工手動選擇繼續執行或者直接回滾，依據是事務日志。

事務開啟時，事務中的操作，都會先寫入存儲引擎的日志緩沖中，在事務提交之前，這些緩沖的日志都需要提前刷新到磁盤上持久化，這就是人們口中常說的“日志先行”(Write-Ahead Logging)

日志分為2種

redo log

保障的是事務的持久性和一致性

在系統啟動的時候，就已經為redo log分配了一塊連續的存儲空間，以順序追加的方式記錄redo log，通過順序io來改善性能

所有的事務共享redo log的存儲空間，它們的redo log按語句的執行順序，依次交替的記錄在一起

如果數據庫崩潰或者宕機，那么當系統重啟進行恢復時，就可以根據redo log中記錄的日志，把數據庫恢復到崩潰前的一個狀態。未完成的事務，可以繼續提交，也可以選擇回滾，這基于恢復的策略而定。

undo log

保障了事務的原子性

主要為事務的回滾服務

undo log記錄了數據在每個操作前的狀態，如果事務執行過程中需要回滾，就可以根據undo log進行回滾操作

redo log和undo log的過程分析

eg : 假設有2個數值，分別為A和B，值為1，2

1 start transaction;

2 記錄 A=1 到undo log;

3 update A = 3；

4 記錄 A=3 到redo log；

5 記錄 B=2 到undo log；

6 update B = 4；

7 記錄B = 4 到redo log；

8 將redo log刷新到磁盤

9 commit

在1-8的任意一步系統宕機，事務未提交，該事務就不會對磁盤上的數據做任何影響.

如果在8-9之間宕機，恢復之后可以選擇回滾，也可以選擇繼續完成事務提交，因為此時redo log已經持久化

若在9之后系統宕機，內存映射中變更的數據還來不及刷回磁盤，那么系統恢復之后，可以根據redo log把數據刷回磁盤

總結

以上是生活随笔為你收集整理的mysql宕机恢复_mysql突然宕机后事务如何处理？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。