mysql突然宕機后事務如何處理？

針對突然宕機的問題
不會自動繼續執行，不會自動直接回滾，但是可以人工手動選擇繼續執行或者直接回滾，依據是事務日志。
事務開啟時，事務中的操作，都會先寫入存儲引擎的日志緩沖中，在事務提交之前，這些緩沖的日志都需要提前刷新到磁盤上持久化，這就是人們口中常說的“日志先行”(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把數據刷回磁盤