当进行数据变更时，为了保证写入效率，数据并非是实时写到文件的，而是先进行内存中的变更，同时记录下变更日志，即RedoLog 和 BinLog。这种先写日志，后写磁盘的技术，即为WAL 技术【Write-Ahead Logging】

1. RedoLog是innodb 存储引擎层特有的存储日志，是物理日志，记录的是“xx页号，xx偏移量的数据修改为xxx”。

2. RedoLog使用多个文件进行循环写【比如4个1GB的文件】，新的记录会添加到write position位置。当write position追上check point时，则必须停止写入，将check point向前推进【将check point位置的数据刷到文件】。
   

3. BingLog是Server层的日志，是逻辑日志，记录的是 “给 ID=2 这一行的 c 字段加 1”

4. 当执行 update T set c=c+1 where ID=2 这段sql时，结合Redo Log两阶段提交方案，整体的执行逻辑如下（图中浅色框表示是在 InnoDB存储引擎内部执行的，深色框表示是在执行器中执行的。）：
   

5. innodb_flush_log_at_trx_commit参数用于控制合适将redo log刷到磁盘上。可选值有0、1、2，默认为1。0表示每秒将日志从用户态缓存刷新到系统态缓存，且从系统态缓存刷新到磁盘日志文件；1 表示每次事务提交，都将日志从用户态缓存刷新到系统态缓存，且从系统态缓存刷新到磁盘日志文件；2表示每次事务提交，都将日志从用户态缓存刷新到系统态缓存，但每秒才将日志从系统态缓存刷新到磁盘日志文件。

6. sync_binlog这个参数用于设定binary log同步到磁盘的频率（刷新二进制日志到磁盘），默认是0，意味着mysql并不刷新，由操作系统自己决定什么时候刷新缓存到持久化设置，如果这个值比0大，它指定了两次刷新到磁盘的动作之间间隔多少个事务。比如sync_binlog=1，表示每进行1次事务提交之后，binlog就会刷新到磁盘对应的日志文件。由此可见，只要binlog日志文件里面有某条记录，则一定表示该次操作已被commit了。

7. 两者的作用
   a. BinLog 作用：用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步；用于数据库的基于时间点的还原【找到某个时间点的备份，回放该时间点之后的BinLog】。

   b. RedoLog 作用：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据磁盘上的redo log+binLog，确定事务是否有提交，从而达到事务的持久性这一特性：

   ⅰ. redo log日志文件中的记录处于prepare状态，但是没有对应的binlog日志，则表明该事务未提交，需要回滚
   ⅱ. redo log日志文件中的记录处于prepare状态，有binlog日志，但是没有commit状态的redo log记录，则进行提交
   ⅲ. redo log日志文件中有commit状态的记录，则进行事务提交

   c. 两者的作用之一都有还原数据库。但是两者有本质区别：redo log是保证事务的持久性的，是事务层面的；binlog作为还原的功能，是数据库层面的。虽然都有还原的意思，但是其保护数据的层次是不一样的。