<aside> 💡 其中redo和undo和事务息息相关。

</aside>

mysql中的日志文件

1. 重做日志（redo log）
2. 回滚日志（undo log）
3. 二进制日志（binlog）
4. 错误日志（errorlog）
5. 慢查询日志（slow query log）
6. 一般查询日志（general log）
7. 中继日志（relay log）

mysql的几大日志文件

redo log（重做日志)

• 作用

  确保事务的持久性。

  防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

• 内容

  物理格式的日志，记录的是物理数据页面的修改的信息，其redo log是顺序写入redo log file的物理文件中去的。

• 什么时候产生?

  事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。

• 什么时候释放?

  当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

• 其他🌟

  很重要一点，redo log是什么时候写盘的？前面说了是在事物开始之后逐步写盘的。

  之所以说重做日志是在事务开始之后逐步写入重做日志文件，而不一定是事务提交才写入重做日志缓存，原因就是，重做日志有一个缓存区Innodb_log_buffer，Innodb_log_buffer的默认大小为8M(这里设置的16M),Innodb存储引擎先将重做日志写入innodb_log_buffer中。

  然后会通过以下三种方式将innodb日志缓冲区的日志刷新到磁盘

  1. Master Thread 每秒一次执行刷新Innodb_log_buffer到重做日志文件。
  2. 每个事务提交时会将重做日志刷新到重做日志文件。
  3. 当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件

  由此可以看出，重做日志通过不止一种方式写入到磁盘，尤其是对于第一种方式，Innodb_log_buffer到重做日志文件是Master Thread线程的定时任务。

  因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。

  另外引用《MySQL技术内幕 Innodb 存储引擎》（page37）上的原话：

  即使某个事务还没有提交，Innodb存储引擎仍然每秒会将重做日志缓存刷新到重做日志文件

  <aside> 💡 这一点是必须要知道的，因为这可以很好地解释再大的事务的提交（commit）的时间也是很短暂的

  </aside>

undo log（回滚日志）

• 作用 提供回滚和多个行版本控制(MVCC)。
• 内容 逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。
• 什么时候释放 当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。
• 对于的物理页
• 其他 Undo是在事务开始之前保存的被修改数据的一个版本，产生undo日志的时候，同样会伴随类似于保护事务持久化机制的redolog的产生。 默认情况下undo文件是保持在共享表空间的，也即ibdatafile文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的undo信息，全部保存在共享表空间中的。 因此共享表空间可能会变的很大，默认情况下，也就是undo 日志使用共享表空间的时候，被“撑大”的共享表空间是不会也不能自动收缩的。 因此，mysql5.7之后的“独立undo 表空间”的配置就显得很有必要了。
• 其他版本的解释 在数据修改的时候，不仅记录了redo，还记录了相对应的undo，如果因为某些原因导致事务失败或回滚了，可以借助该undo进行回滚。 Undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。 🌟当执行 rollback 时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制（MVCC）的时候，也是通过 undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。 undo log是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment 另外，undo log也会产生redo log，因为undo log也要实现持久性保护。

➡️undo log 的存储方式 ➡️和undo log相关的变量 ➡️delete/update操作的内部机制 ➡️binlog和事务日志的先后顺序及group commit

binlog(二进制日志)