mysql中redo log和binlog的恩恩怨怨

mysql架构可以分为两层，server层和存储引擎层。
server层是负责功能方面的，而存储引擎层则负责处理与存储相关的操作。

redo log 是innodb存储引擎层持有的，是物理日志，闭环循环写。
redo log（重做日志）是实现事务持久性必备要素，当一个事务提交后，会在redo log中记录相关操作，再修改数据库数据。
Innodb存储引擎中的redo log大小是固定的，每个文件大小默认为48M，使用innodb_log_file_size参数来控制单个文件大小

binlog是逻辑日志，记录的是一条更新语句的执行逻辑。binlog是追加写的，这个文件写完了，换下一个文件，不会覆盖以前的日志。这也就是你经常看到只要你有完整的binlog文件就可以给你恢复到你想要的数据。

所以使用innodb会写两份日志，即两阶段提交。
update user set num= num+ 1 where id = 1

执行器会先到引擎层找到id=1这条数据，去主键索引树寻找这一行，如果id=1这一行的数据页存在内存中，就直接返回给执行器，否则，去磁盘读入内存再返回。
执行器拿到数据后，进行num+1操作，调用引擎接口写入更新后的数据。
引擎先将数据更新到内存中，将更新操作记录到redo log中，redo log处于prepare状态，即执行已经完成，随时可以提交事务。
然后执行器生成更新操作的binlog写入磁盘
最后，执行器调用引擎的事务提交接口，引擎把redo log的状态改为commit，更新完成。

事务的持久性是通过重做日志来实现的。
当有DML操作时，数据会先写入Buffer pool，然后再写入到redo log buffer（重做日志缓冲区），重做日志缓冲区会根据刷盘机制（innodb_flush_log_at_trx_commit，参数分别为0，1，2）写入重做日志中。
0：提交事务后，会把数据放到redo log buffer中，然后每秒写入磁盘文件。
1：提交事务后，就直接把redo log buffer从内存刷入磁盘文件中去。
2：提交事务后，把redo log buffer 刷入os cache，每秒把os cache里的数据写入到磁盘文件里去。
刷盘策略默认值为1，保证事务提交之后，数据绝对不会丢失。