1. redo log
1.1 特点
InnoDB存储引擎独有- 物理日志，记录在数据页上做的修改
- 让
MySQL拥有了崩溃恢复能力，保证事务的持久性
1.2 刷盘时机
- 事务提交时
- log buffer 空间使用大约一半时
- 事务日志缓冲区满
- InnoDB 定期执行检查点Checkpoint
- 后台刷新线程，1s一次
- MySQL 关闭
1.3 刷盘策略
- 设置为 0 的时候，表示每次事务提交时不进行刷盘操作，最不安全。
- 设置为 1 的时候，表示每次事务提交时都将进行刷盘操作，最安全。
- 设置为 2 的时候，表示每次事务提交时都只把 log buffer 里的 redo log 内容写入 page cache，安全性介于0和1之间。
2. bin log
2.1 特点
- 属于
MySQLServer 层 - 逻辑日志，记录内容是语句的原始逻辑
用于MySQL数据库的数据备份，保证数据一致性
2.2 记录格式
- statement 记录的内容是
SQL语句原文 - row 为解决数据不一致 的问题，记录的内容包括
SQL语句和具体数据
- mixed 根据
MySQL判断这条SQL语句是否可能引起数据不一致的结果决定使用row格式或statement格式。
2.3 刷盘策略
- 为
0表示每次提交事务都只write，由系统自行判断什么时候执行fsync。 为1表示每次提交事务都会执行fsync- 为
N(N>1)表示每次提交事务都write，但累积N个事务后才fsync
3. undo log
3.1 特点
- 保证事务的原子性
3.2 作用
- 事务回滚时将数据恢复到修改前的状态
MVCC的实现，事务通过undo log读取之前的版本数据
4.redo log vs bin log
|----------|---------|--------------|-------|
| | 位置 | 写入时机 | 作用 |
| redo log | 存储引擎层 | 事务执行过程可以不断写入 | 崩溃恢复 |
| bin log | server层 | 提交事务时才写入 | 数据一致性 |
5. 两阶段提交
将redo log的写入拆成了两个步骤prepare和commit
MySQL根据redo log日志恢复数据时，发现redo log还处于prepare阶段，并且没有对应binlog日志，就会回滚该事务。
从而解决了redo log 和 bin log 日志之间的逻辑一致问题。