第二讲 日志系统：一条SQL更新语句是如何执行的

redo log（重做日志）和 binlog（归档日志）

Write-Ahead Logging 写前日志技术
MySQL 里经常说到的 WAL 技术 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘
先写入redo log,可以避免每次写磁盘低效的I/O,并且使用redo log日志还是顺序写入
InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB 0 1 2 3 循环使用

redo log bin log 对比
redo log 是 InnoDB 引擎特有的 它使InnoDB有crash safe能力,binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志
redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的

两阶段提交:redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。
update 语句：执行器先通过引擎获取要修改的行,将更新之后的数通过调用引擎接口写入这行新数据,引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态,然后返回,执行器生成这个操作的 binlog,并把 binlog 写入磁盘。执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

不用两阶段提交 crash之后
先写 redo log 后写 binlog 少一行
先写 binlog 后写 redo log 由于事务回滚 恢复的备库多一行