MySQL-日志-深入解析

1、redolog，undolog，binlog

• redo log
  -重做日志文件，记录数据修改之后的值，用于持久化到磁盘中。
  -包括两部分：1是内存中的日志缓冲，是易失性的；2是磁盘上的重做日志文件，是持久性的；
  -由InnoDB引擎实现，是物理日志，记录的是物理数据页修改后的信息。
  -当一条数据需要更新时，InnoDB会先将数据更新，然后记录redoLog 在内存中，然后找个时间将redoLog的操作刷新到磁盘上的文件上。
  -不管事务是否提交成功，都会被记录，确保了事务的持久性。

• undo log
  -回滚日志文件，主要用于事务中执行失败时进行回滚，以及MVCC/多版本并发控制中对数据历史版本的查看。
  -由InnoDB引擎实现，属于逻辑日志，记录数据被修改前的值：当一条数据需要更新前会把修改前的值存储到undolog中，当修改出现异常时使用undo log实现回滚操作，确保事务的一致性。
  -事务提交之后，undo log不会马上删除，会存放在待清理链表中，由purge线程判断没有事务用到该版本的信息时才可以清理相应undo log。
  -对回滚和多版本并发控制的支持确保了数据的原子性。

• bin log
  -逻辑日志，记录SQL语句的原始逻辑
  -由MySQL的Server层实现
  -产生：事务提交的时候，一次性将事务中的sql语句，按照一定的格式记录到binLog中。
  -用于复制和恢复，在主从复制中，从库利用主库上的binlog进行重播(执行日志中记录的修改逻辑)，实现主从同步。业务数据不一致或者错了，用binlog恢复。

2、binlog和redolog的区别

1. redo log是在InnoDB存储引擎层产生，而bin log是MySQL数据库的上层服务层产生的。
2. redo log是物理日志，记录该数据页更新的内容；binlog是逻辑日志，记录的是这个更新语句的原始逻辑 。
3. 两种日志与记录写入磁盘的时间点不同，binlog日志只在事务提交完成后进行一次写入。而innodb存储引擎的重做日志在事务进行中不断地被写入，并且日志不是随事务提交的顺序进行写入的。
4. redo log是循环写，日志空间大小固定；binlog是追加写，是指一份写到一定大小的时候会更换下一个文件，不会覆盖。
5. binlog可以作为恢复数据使用，主从复制搭建，redolog作为异常宕机或者介质故障后的数据恢复使用。

3、事务日志有哪些？区别是什么？

有redolog和undolog

• 1、redolog是重做日志，提供前滚操作；undolog是回滚日志，提供回滚操作。
• 2、redolog通常是物理日志，记录的是数据页的物理修改；undolog是逻辑日志，根据每行的记录进行记录
• 3、redoLog：每当有操作执行前，将数据真正更改时，先前相关操作写入重做日志。这样当断电，或者一些意外，导致后续任务无法完成时，系统恢复后，可以继续完成这些更改
  undoLog：当一些更改在执行一半时，发生意外，而无法完成，则可以根据undoLog恢复到更改之前的状态