MySQL为什么需要redolog和undolog？从数据页刷盘的四种策略考虑

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