redo log
事务提交后，必须将事务对数据页（会涉及多个数据页）的修改刷(fsync)到磁盘上，才能保证事务的ACID特性。
这个刷盘，是一个随机写，随机写性能较低，如果每次事务提交都刷盘，会极大影响数据库的性能。
随机写性能差，有什么优化方法呢？
架构设计中有两个常见的优化方法：
（1）先写日志(write log first)，将随机写优化为顺序写；
（2）将每次写优化为批量写；
这里先写日志，写的就是redo log，redo log记录着物理层面对页信息的修改记录，包括存储表空间ID、页号、偏移量以及需要更新的值
redo log的作用
保证数据的持久性，防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做。
什么时候产生?
事务开始之后就产生redo log，在事务的执行过程中对页物理结构的修改都会产生redo log， 生成的redo log 会直接写到redo log buffer区中
什么时候释放？
当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）
什么时候同步到磁盘？
三种策略：
策略一：最佳性能(innodb_flush_log_at_trx_commit=0)
每隔一秒，才将Log Buffer中的数据批量write入OS cache，同时MySQL主动fsync。
这种策略，如果数据库奔溃，有一秒的数据丢失。
策略二：强一致(innodb_flush_log_at_trx_commit=1)
每次事务提交，都将Log Buffer中的数据write入OS cache，同时MySQL主动fsync。
这种策略，是InnoDB的默认配置，为的是保证事务ACID特性。
策略三：折衷(innodb_flush_log_at_trx_commit=2)
每次事务提交，都将Log Buffer中的数据write入OS cache；
每隔一秒，MySQL主动将OS cache中的数据批量fsync。
这种策略，如果操作系统奔溃，最多有一秒的数据丢失。
策略三为不考虑强一致性时的推荐策略，和策略一性能差异不大，但是安全性要高很多，因为操作系统崩的概率要小于数据库崩的概率。
undo log
提供回滚和多个行版本控制(MVCC)
undo log不同于redo log, 是逻辑日志
当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。
undo log 保证事务的原子性
binlog
用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步, 用于数据库的基于时间点的还原
逻辑格式的日志
事务提交的时候，一次性将事务中的sql语句（一个事务可能对应多个sql语句）按照一定的格式记录到binlog中
参考:
https://blog.csdn.net/suifeng629/article/details/102560575
https://www.pianshen.com/article/15501165741/
