MySQL Undo Log、Redo Log、bin Log

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