INNODB事务执行流程

4、写redo日志

RedoLog Buffer

binlog文件

IO线程刷入磁盘

BufferPool缓冲池

page cache

执行器

7、写入binlog文件与位置，写入commit标记

操作系统内存也就是文件系统这里并未持久化

1、加载缓存数据

INNODB引擎

磁盘文件

undolog

6、事务进行中刷入binlog cache

3、更新内存数据

binlog cache

5、特定情况下redolog刷入磁盘详情见（一）

5、准备提交事务，redolog刷入磁盘

2、写入旧数据便于回滚

6、提交事务时，把cache刷入磁盘

一、redo log有三种状态1、存在redo log buffer中2、page cache中，但是没有持久化3、磁盘文件中持久化，也就是硬盘中为了控制 redo log 的写入策略， InnoDB 提供了 innodb_flush_log_at_trx_commit 参数，它有三种可能取值：1.  设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;（不建议）2.  设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘；3.  设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache 。 同时，innodb中有一个后台线程，每隔一秒，就会把 redo log buffer 中的日志，调用 write 写到文件系统的page cache ，然后调用 fsync 持久化到磁盘。这就是后台线程的轮询操作实际上，除了后台线程每秒一次的轮询操作外，还有两种场景会让一个没有提交的事务的 redolog 写入到磁盘中。1.  一种是， redo log buffer 占用的空间即将达到 innodb_log_buffer_size 一半的时候，后台线程会主动写盘。这个写盘动作只是 write ，而没有调用 fsync ，也就是只留在了文件系统的 page cache中。2.  另一种是，并行的事务提交的时候，顺带将这个事务的 redo log buffer 持久化到磁盘。假设一个事务 A 执行到一半，已经写了一些 redo log 到 buffer 中，这时候有另外一个线程的事务 B 提交，如果 innodb_flush_log_at_trx_commit 设置的是 1 ，那么按照这个参数的逻辑，事务 B 要把 redo log buffer 里的日志全部持久化到磁盘。这时候，就会带上事务 A 在 redolog buffer 里的日志一起持久化到磁盘。我们经常把innodb_flush_log_at_trx_commit 设置成 1，那么 redo log 在 prepare 阶段就要持久化一次（因为所谓的 redo log prepare ，是 “ 当前事务提交 ” 的一个阶段）因为有一个崩溃恢复的判断逻辑是要依赖于 prepare  的 redo log ，再加上 binlog 来恢复的，所以必须把它持久化

redolog文件