455-MySQL(redo log重做日志)

我们回顾一下：

持久性：当事务提交之后，不管MySQL server会出现什么不可预期的错误，哪怕是进程挂了，断电了，只要事务提交成功，由MySQL-server处理完异常后把数据恢复到正常状态

redo log 重做日志

redo log：重做日志，用于记录事务操作的变化，确保事务的持久性。
redo log是在事务开始后就开始记录（并不是事务commit时才记录，因为整个事务改的可能有很多，如果在commit的时候才写redo log的话，可能花的时间特别长了。而是事务begin开始后就记录了，随着事务执行过程中对数据的修改，实时写redo log），不管事务是否提交都会记录下来，在异常发生时（如数据持久化过程中掉电），InnoDB会使用redo log恢复到掉电前的时刻，保证数据的完整性。

innodb_log_buffer_size默认是16M，就是redo log缓冲区的大小，它随着事务开始，就开始写redolog，如果事务比较大，为了避免事务执行过程中花费过多磁盘IO，可以设置比较大的redo log缓存，节省磁盘IO。往磁盘上刷是有刷新的时机。达到时机就花费磁盘IO，如果buffer比较大，会更慢的达到刷新的时机，效率更快。

InnoDB修改操作数据，不是直接修改磁盘上的数据，实际只是修改Buffer Pool中的数据。InnoDB总是先把Buffer Pool中的数据改变记录到redo log中，用来进行崩溃后的数据恢复。 优先记录redo log，然后再找时机慢慢的将Buffer Pool中的脏数据刷新到磁盘上。

innodb_log_group_home_dir指定的目录下的两个文件：ib_logfile0，ib_logfile1，该文件被称作重做日志。
buffer pool缓存池：（B+树索引，自适应哈希）
作用：加速读和加速写，直接操作data page，写redo log修改就算完成，有专门的线程去做把buffer pool中的dirty page写入磁盘。

弧形：是奔溃的恢复。通过redo log恢复上次事务提交成功后的数据。
MySQL server：检查一些连接，SQL的优化操作
然后就是存储引擎（绿色）

黄色的柱状就是磁盘

左边绿色的是日志缓存，专门的重做日志的缓存，写日志写索引是不可能直接往磁盘上写的，但是最终记录在磁盘上。
右边绿色的就是缓存池，就是数据缓存，索引缓存，最终发送到磁盘上。

当我们在数据更新，数据操作的时候，事务开始以后，随着事务执行一些相应的SQL，这些对数据的最终更改都是先记录在redo log buff（专门做redo log的缓冲区）里面，对于数据或者索引的修改都是先记录在buff poll（在buffpool建B+索引树，B+树索引优化的自适应哈希）里面。
当我们提交事务commit的时候，在关系图上的操作就是把InnoDB Log Buffer的内容写入磁盘，写成功的话，在磁盘上的redo log会记录状态：commit，如果没有写成功或者写完，就是记录状态：prepare

在写入磁盘的过程中也有可能发生异常，掉电，服务崩溃，导致在写redo log的时候没有写完，出错了，这个相当于事务没有提交成功，此时MySQL下次在恢复的时候就没有必要考虑这个事务的完整性，因为状态并不是commit，都写入磁盘上才表示redo log写成功，状态才变成commit。

是不是commit的时候，buff poll里面的脏数据（数据有被修改）写入磁盘？
并不需要和commit操作同步。
因为进入数据修改的时候，当前事务可能修改的数据量还是比较大的，对于buff poll缓存的数据，我们有专门的线程在合适的时间，往磁盘上去刷新，如果出现掉电，下一次mysql启动后，会根据redo log里面记录的数据，对数据进行恢复。undo log也要记录在redo log中

undo log支持事务回滚，也不是一瞬间就发生了，最终要修改的也是磁盘上的数据，要防止在回滚中出现异常，所以要记录在redo log里面。
事务commit成功或者rollback成功，对于底层，都是成功的把操作写到redo log里面。

当我们去事务commit成功的时候，最重要的是redo log内容成功刷新到磁盘上，会把数据的状态改为commit，这才算一个真真正正的事务提交成功，数据还是buff pool，此时其他的事务查询还是从buff pool查询，没有直接从磁盘查，buff pool有专门的刷新到磁盘的时间和机制。最重要的不是写数据到磁盘。
undo log也要记录在redo log中 因为undo log也要支持事务回滚 ，事务回滚也不是一瞬间发生，最终要修改的是磁盘上的数据，如果在回滚中出现异常，mysql重启后也能从redo log中找到undo log的内容，重启事务的回滚，把事务恢复到最初的状态。体现事务的原子性！

redo log里面记录的就是最终修改后的按页面存储的数据页（物理日志）。直接存数据最终的状态。

undo log是逻辑日志，存储的是具体的相应的SQL语句。如果现在执行的是insert，回滚的时候就执行delete；如果现在执行的update，就把原来的旧值再update回来。

事务commit成功或者rollback成功，从表面来说，函数执行成功，对于业务来说是成功的，但是对于底层来说，都是要成功的把相应的操作写入到redo log中。写入到redo log成功，才算真真正正的成功，才能保证原子性，一致性，尤其是数据的持久性。

默认大小是16M

重做日志的文件

看下图所示：

读出来的，修改的都是优先修改缓存池中的东西
在实际项目中，mysqld会单独的跑在一个机器上，可以分配大量的内存专门做InnoDB的buffer pool，性能还是非常不俗的。

看看buff pool的大小：
默认大小是134M

当我们在进行事务更改的时候，永远先写的是redo log，然后才是写buff pool，当事务提交成功，就是要保证redo log就记录完整到磁盘上。
对于表数据的更改，buff pool的脏数据是不是刷新到磁盘上，我们根本不用担心，因为我们可以随时通过redo log重做日志来恢复事务提交成功的状态。