redo log 是InnoDB存储引擎层的日志，其他存储引擎不存在的 bin log是服务层的日志，不区分存储引擎
redo log 是物理日志，记录的是"在 XXX 页上做了 XXX 修改"; binlog 是逻辑日志，比如" 给 id = 2 这一行的 c 字段加 1"
redo log 是有固定大小的，所以它的空间会用完，如果用完的话，一定要进行一些写入磁盘的操作才可以继续; binlog 是可以追加写入的，也就是 binlog 没有空间的概念，一直写就行了
redo log的主要作用
当update等操作附带的where条件，需要先检索再更新。如果数据量很大，查询复杂这样直接处理再写到磁盘IO代价很大，
因此可以记录在redo log 同时更新内存，这样就算update成功了，InnoDB等到合适时机再把数据更新到磁盘。(WAL 技术，也就是 WriteAheadLogging ，核心就是先写日志，再写磁盘)
redo log 不能一直写吧？如果更新操作一直写入到 redo log 中的话，不限制大小的话，可能服务器上的存储空间都被 redo log 给占满了
所以redo log写一段时间后会写入磁盘，然后即时清理
所以 InnoDB 的 redo log 是固定大小的，比如我们配置了一组 4 个文件，每个文件大小是 1GB ，那么它的操作可能就会这样:
主要就是 write pos 和 checkpoint ， write pos 比较好理解，它就是当前记录的位置，有需要记录的操作就从当前位置向后移，等把 ib_logfile_3 写完之后，就回到 ib_logfile_0 文件开头继续写
checkpoint 是当前要擦除的位置，就是 InnoDB 引擎不是会在恰当的时候，将这些操作进行持久化，更新到磁盘上去，那持久化之后的数据是不是就可以擦除了
write pos 和 checkpoint 之间的部分就是可以用来记录操作的部分，那么如果 write pos 和 checkpoint 相遇了怎么办？相遇了是不是说明这个时候分配的 redo log 大小用完了，那这时候就不能再进行更新操作了，必须停下来处理一下，将 checkpoint 往前推推才行
就是因为有了 redo log ，所以 InnoDB 才可以保证即使数据库发生了异常重启，也没关系，之前提交的记录都还在，只需要根据 redo log 里面的记录进行相应恢复就可以了
udpate一条例子
我现在要给 id = 2 这一行的 c 字段加 1，到 MySQL 层面
首先，会先找到这条 id = 2 的数据，然后找到 c 字段进行加 1 操作，这个时候，引擎会将这行数据更新到内存中，同时把这个更新操作记录到 redo log 里面，这个时候 redo log 处于 prepare 状态，随后执行器生成这个操作的 binlog ，并且把 binlog 写入到磁盘完成之后，执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 从 prepare 状态改成 commit 状态，这样更新操作才算完成
这就是传说中的的”两阶段提交“，保证了redo log 和 bin log 数据一致