- redo log日志，发生：事务开始之后（不是事务提交的时候）原因是有一个indodb_log_buffer 缓冲区，默认大小为8M，innodb引擎先将重做日志写入innodb_log_buffer中
- 从缓冲区刷入到磁盘中有3这种方法：
- Master Thread（定时任务） 每秒一次执行刷新Innodb_log_buffer到重做日志文件。
- 每个事务提交时会将重做日志刷新到重做日志文件。
3）重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件
二、回滚日志（undo log）（1）保证数据的原子性，保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC）
（2）逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的
（3）发生在事务开始之前，当前生成快照，同时也会产生redo日志来保证undo log可靠
（4）什么时候释放：
当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。
三、二进制日志（binlog）（1）用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。
（2）事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。
（3）binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。
：redo log是保证事务的持久性的，是事务层面的，binlog作为还原的功能，是数据库层面的
：redo log是物理日志，是数据页面的修改之后的物理记录，binlog是逻辑日志，可以简单认为记录的就是sql语句
另外，两者日志产生的时间，可以释放的时间，在可释放的情况下清理机制，都是完全不同的。
