1、MySQL日志系统
redo log(重做日志)
Innodb引擎持有
WAL技术
Write-Ahead Logging，先写日志再写磁盘。当一条记录需要更新时，InnoDB引擎先把记录写到redo log里面，并更新内存，这次更新就算完成了。InnoDB引擎会在适当时候将这个操作记录更新到磁盘。
执行过程
write pos：当前记录位置，一遍写一遍后移。
check point：当前要擦除的位置（更新到磁盘），往后推移。
write pos和check point之间可以用来记录新的操作；当write pos追上check point时，此时不能再执行新的更新；需要等待check point擦除一部分记录再执行更新。
基于redo log，InnoDB可以保证数据库发生异常重启，之前提交的记录都不会丢失，即crash-safe。
binlog日志（server层日志）
redo log与binlog日志不同点
| 适用范围 | 记录类型 | 写入方式 | |
|---|---|---|---|
| redo log | InnoDB引擎特有 | 物理日志；记录“在某个数据页做了什么修改” | 循环写；空间固定会用完 |
| binlog | Server层实现，所有引擎都可以使用 | 逻辑日志；记录语句的原始逻辑 | 追加写； |
Update语句执行过程
mysql> update T set c=c+1 where ID=2;
深色：执行器中执行；浅色：InnoDB中执行
此处将redo log的写入拆分为两个步骤：prepare和commit。——两阶段提交
两阶段提交可以保证redo log和binlog的状态保持逻辑一致。（事务性）——可以保证数据恢复
相关设置
- innodb_flush_log_at_trx_commit：设置为1，每次事务的redo log都直接持久化到磁盘；保证mysql异常重启数据不丢失；
- sync_binlog：设置为1，每次事务的binlog都持久化到磁盘；保证mysql异常重启后binlog不丢失。
MySQL如何判断binlog完整
一个事务的binlog是有完整格式的：
- statement格式的binlog，最后会有COMMIT；
- row格式的binlog，最后会有一个XID event。
5.6.2版本以后，引入了binlog-checksum参数，用来验证binlog内容的正确性。
redolog和binlog如何关联
他们有一个共同的数据字段XID。崩溃恢复的时候，会顺序扫描redo log：
- 如果碰到既有prepare，又有commit的redo log，就直接提交；
- 如果碰到只有prepare，没有commit的redo log，就拿着XID去binlog找对应的事务。
