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来一起解决上面说的内存数据丢失的问题。