Mysql数据库面试必备之三大log介绍-木庄网络博客

本文整理自网络，侵删。

一、redo log 重做日志（MySQL 存储引擎 InnoDB 的事务日志）

我们知道 MySQL 数据存在磁盘中，每次读写数据需做磁盘 IO，并发场景下性能差。为此 MySQL 引入缓存 Buffer Pool 做优化。其包含磁盘中部分数据页（page）的映射，来缓解数据库的磁盘压力。

当从数据库读数据时，首先从缓存中读，缓存中没有，则从磁盘读后放入缓存；当向数据库写数据时，先向缓存中写，此时缓存中的数据页数据会变更，该数据页叫脏页，Buffer Pool 中修改完数据后会按照设定的策略再定期刷到磁盘中去，这个过程叫刷脏页。

那么问题来了，如果 Buffer Pool 中修改的数据还没有及时的刷到磁盘，MySQL 宕机重启，就会导致数据丢失，无法保证事务的持久性，怎么办？

redo log 解决了这个问题。就是说数据库在修改数据时，会把更新记录先写到 redo log 中，再去修改 Buffer Pool 中的数据，当提交事务时，调用 fsync 把 redo log 刷入磁盘。至于缓存中更新的数据文件何时刷入磁盘，则由后台线程异步处理。

注意：此时 redo log 的事务状态是 prepare，还未真正提交成功，要等 bin log 日志写入磁盘完成后才会变为 commit，事务才算真正提交成功。

redo log 的写入方式？

redo log 采用大小固定，循环写入的方式，当写满后，会重新从头开始循环写，类似一个环状。这样设计原因是 redo log 记录的是数据页上的修改，如果 Buffer Pool 中数据页已经刷到磁盘，这些记录就失效了，新日志会将这些失效的记录覆盖擦除。

注意：redo log 满了，在擦除之前，要确保这些要被擦除记录都已经刷到磁盘中了。在擦除旧记录释放新空间期间，不能再接收新的更新请求，此时 MySQL 性能会下降。因此高并发情况下，合理调整 redo log 大小很重要。

crash-safe 能力是什么？

Innodb 引擎有 crash-safe 能力，即事务提交过程中任何阶段，MySQL 宕机重启后都能保证事务的完整性，已提交的数据不会丢失。这种能力是通过redo log保证的，MySQL 宕机重启，系统将自动检查 redo log，将修改还未写入磁盘的数据从 redo log 恢复到 MySQL 中。

二、undo log 回滚日志（MySQL 存储引擎 InnoDB 的事务日志）

undo log 记录的是数据修改之前的状态，属于逻辑日志，起到回滚的作用，是保证事务原子性的关键。
举个栗子：假如更新 ID=1 记录的 name 字段，name 原始数据为小王，现改 name 为小张，事务执行 update X set name = 小张 where id =1 语句时，先在 undo log 中记录一条相反逻辑的 update X set name = 小王 where id =1 记录，这样当某些原因导致事务失败，就可借助 undo log 将数据回滚到事务执行前的状态。

那么问题来了：同一个事务的一条记录被多次修改，难道每次都要把数据修改前的状态写 undo log 吗？

阅读剩余部分