Redo Log
重做日志 存储的是已提交的事务，为了事务的持久性/原子性保证提交以后就能真的确定不变 , 也为了快速提交(变成顺序IO了更快)
重做日志文件, 实体是ib_logfie,
记录的是修改信息,事务开始就把变化按顺序记入重做日志缓冲区,一秒了/缓冲区满一半了,就刷到重做日志文件(ib_logfie)
在事务提交时 ,再刷一次缓冲到这个日志，此时事务就算提交了(因此事务提交的速度很快，即使这个事务很大),
之后这个日志再写入磁盘，这个日志文件的使命就完成了，可以往上覆盖新的数据了.如果日志写入磁盘期间发生故障,重启mysql后就按它重做.
记录的是页的物理操作，是顺序写，不需要进行读取操作，顺序io会带来更好的性能优势,物理日志恢复起来比逻辑日志要快，
重做日志缓冲区 可配置大小
字节为单位，不用太大 最多每秒一刷新到磁盘(重做日志文件)
重做日志文件，可配置个数，ib_logfie
https://www.cnblogs.com/wy123/p/8365234.html
https://blog.csdn.net/leonpenn/article/details/72778901
https://www.cnblogs.com/xinysu/p/6555082.html
对数据做修改的时候，需要把数据页从磁盘读到buffer pool(就是内存)中，然后在buffer pool中进行修改，
那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page 脏数据，
如果这个时候发生非正常的DB服务重启，那么这些数据还在内存，并没有同步到磁盘文件中（注意，同步到磁盘文件是个随机IO, 很贵），也就是会发生数据丢失，
如果这个时候，能够在有一个文件，当buffer pool 中的data page变更结束后，把相应修改记录记录到这个文件（注意，记录日志是顺序IO,便宜），那么当DB服务发生crash的情况，恢复DB的时候，也可以根据这个文件的记录内容，重新应用到磁盘文件，数据保持一致。
这个文件就是redo log ，用于记录 数据内存修改后的记录
好处：
- 当buffer pool中的dirty page 还没有刷新到磁盘的时候，发生crash，启动服务后，可通过redo log 找到需要重新刷新到磁盘文件的记录；(持久性)
- buffer pool中的数据直接flush到disk file，是一个随机IO，效率较差，而把buffer pool中的数据记录到redo log，是一个顺序IO，可以提高事务提交的速度；
Undo Log
回滚日志，存储的是未提交的事务，
实现事务的一致性未提交事务的回滚 和 mvcc(多版本并发控制,要select时被刚好其他事务在写,锁住了，按理是不能读的，但是用undo log可以让他读，就是读这个日志保存的之前的快照)
事务开始除了会有redo log还会产生这个undo log日志，回滚时就按这个undo日志回滚，是逻辑日志,记录了我们的操作,回滚的时候按undo日志反序操作就行了，
一般位于共享表空间,新版可以移出
