rt
数据库事务开始之前，会将要修改的记录存放到UNdo日志里，当事务回滚时或数据库崩溃时，可以利用undo日志撤销未提交事务对数据库产生的影响。
逻辑日志，记录一个过程，提交后不会删除。delete insert
采用段的方式管理和记录。在innnodb数据文件中包含一种rollback segment回滚段，
内部包含1024个undo log segment。
show variables like "%innodb_undo%";
作用：
- 实现事务原子性
事务处理过程中，如果出现了错误或者用户执行了rollback语句，mysql可以利用undoLog 中的备份将数据恢复到事务开始前的状态。
- 实现多版本并发控制MVCC
事务未提交之前，undolog 保存了未提交之前的版本数据，undo log中的数据可作为数据旧版本快照供其他并发食物进行快照读。
事务A手动开启事务，执行更新操作，首先会把更新命中的数据备份到undo Buffer中。事务B手动开启事务，执行查询操作，会读取undi日志数据返回，进行快照读
redo log
事务中修改的任何数据，将最新的数据备份存储的位置，被称为重做日志
随着事务操作的执行，就会生成redo log，在事务提交时会将产生redo log写入log buffer，并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入到磁盘之后，redolog的使命也就完成了，Redo log 占用的空间就可以重用（被覆盖写入）。
作用：为了实现事务的持久性。防止在发生故障的时间点，尚有脏页为写入表的IBD文件中，在重启MYSQL服务的时候，根据RedoLog进行重做，从而达到事务的未入磁盘数据进行持久化这一特性。
redoLog 是顺序写 同步？
其实不然，参考https://blog.****.net/m0_37264516/article/details/99480237
用的还是非同步的io。只保证刷到页告诉缓存，优势在于，顺序写，写之前的查 缓存命中率高
顺序循环写的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。
Binlog
不是innodb独有，是mysql server自己的日志。
主从复制：在主库中开启，主库就可以把binlog传递给从库，从库拿到binlog后实现数据恢复达到主从数据一致性。
数据恢复：通过mysqlbinlog工具来恢复数据。
文件结构：
binlog和redlog区别
redolog 是属于innodb，binlog是属于mysql server自带功能。
redo log属于物理日志，记录该数据页更新状态内容，binlog是逻辑日志，记录更新过程
redo log日志是循环写，日志空间大小是固定。binlog是追加写入， 写完一个写下一个，不回覆盖使用。
redo log作为服务期异常宕机后事务数据自动恢复使用。binlog可以作为主从复制和数据恢复使用。binlog没有自动crash-safe功能