Undo Log
回滚日志，用于将数据回滚到之前的状态。
MySQL在进行数据的增、删、改时，会将数据写入到Undo Log日志中。
对于Undo Log存在着insert和update两种类型的数据。插入语句对应的是insert类型，修改、删除语句对应的是update类型。
Undo Log以段的方式管理和记录日志信息，在Innodb存储引擎的数据文件中，包含一种叫rollback segment的回滚段，每个段内部包含了1024个undo log senment。
-
Undo Log实现了事务的原子性
- 通过Undo Log可以将数据恢复到修改的前的版本，以实现事务的原子性
-
MVCC事务多版本控制也是通过Undo Log日志实现的
- 在innodb存储引擎中创建的表，每行数据都记录着三个隐藏的字段，DB_TRC_ID、DB_ROLL_PTR、DB_ROW_ID。
- 在一个事务当中对数据进行修改时，Undo Log日志中的数据会根据DB_TRC_ID、DB_ROLL_PTR形成一个链表
- 通过当前事务的ID以及Redo Log中根据当前事务生成的链表，实现了多版本并发控制。
-
Undo Log日志在事务提交后并不会立刻删除，会通过一个后台purge线程进行处理。
Redo Log
重做日志，对于数据的增、删、改操作，在buffer中完成数据的修改后，并不会即时将数据写入磁盘。而是会将修改操作以顺序循环的方式写入到Redo Log中。
- 频繁写入磁盘会消耗很多的时间，降低响应速度
- 写入磁盘时并不是顺序写入，需要找到需要写入的位置在进行写入。
- Redo Log日志是顺序写入的，不用找到磁盘中的具体位置后再写入。
- Redo Log日志也不是即时持久化的。
- 每秒执行一次持久化
- 每次事务提交时执行一个持久化
- 每次事务提交时，从Redo Buffer缓存中放到系统缓存中，在每秒刷新一下缓存。默认使用该机制。可以保证MySQL服务挂机不丢失数据，系统挂机最多就是1S数据。
Bin Log
记录MySQL数据库表机构一级数据修改的二进制日志。日志格式是以时间形式记录，同时记录了语句的消耗时间。
- 可用于主从复制
- 通过mysqlbinlog等日志进行数据恢复。
文件记录模式
Binlog文件记录模式有STATEMENT、ROW和MIXED三种。
- ROW：记录每一行的修改情况，修改记录会非常清晰，但会产生大量的日志
- STATEMENT：记录SQL语句，日志量小，同步快，但对于一些函数操作，比如date()获取时间的，会不一致。
- MIXED：STATEMENT、ROW的混合模式，一般使用STATEMENT模式，但对于无法完全复制的操作会使用ROW模式。
MVCC
todo
其它
MySQL的每行数据，除了明确定义的字段外，还会存在三个隐藏的字段。
| 隐藏字段 | 字段含义 |
|---|---|
| DB_TRC_ID | 用于记录最后一个修改/插入过记录的事务ID |
| DB_ROLL_PTR | 回滚指针，指向记录的上一个版本 |
| DB_ROW_ID | 隐藏的自增ID，表没有指定ID时，会使用该字段作为自增ID |