1 針對未提交事務的刷盤策略
No Steal和Steal
- No Steal：未提交的事務數據頁不可以寫入磁盤
- Steal：未提交的事務數據頁可以寫入磁盤
2 針對提交事務的刷盤策略
No Force和Force
- No Force：提交的事務數據頁必須寫入磁盤
- Force：提交的事務數據頁也可以不寫入磁盤
3 排列組合
- 第一種情況：No Steal和Force，即未提交事務不可以寫入磁盤，提交事務必須寫入磁盤
如果系統宕機了，此時未提交的事務修改的數據頁還停留在內存中，斷電后重啟，內存中的數據自然也就消失了，自動回滾；而對於已經提交的事務，根據Force的策略，其修改的數據頁已經寫入到磁盤進行持久化后，並沒有收到影響，此時系統數據一致性可以得到保障。但是會出現什么問題呢？每次事務都要做一次磁盤IO，這樣的性能是無法接受的。 - 第二種情況：No Steal和No Force，即未提交事務不可以寫入磁盤，提交事務可以暫不寫入磁盤
如果系統宕機了，未提交事務並不會收到影響，自動回滾掉，但是已提交的事務對應的臟頁就沒了，為了解決數據的一致性，MySQL引入了redolog機制，可以提供數據回放，解決內存數據丟失的問題。 - 第三種情況：Steal和Force，即未提交事務可以寫入磁盤，提交事務必須寫入磁盤
如果系統宕機了，已提交的事務，其修改的數據頁已經寫入到磁盤進行持久化后，並沒有收到影響。但是未提交事務，已經修改的數據頁持久化到了磁盤中，為了解決數據的一致性問題，引入undolog機制，提供數據快照，並往歷史版本回滾。 - 第四種情況：Steal和No Force，即未提交事務可以寫入磁盤，提交事務可以暫不寫入磁盤
此時就必須引入redolog和undolog來一起解決上面說的內存數據丟失的問題。