MySQL三大日志

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 特点

• 属于MySQL Server 层
• 逻辑日志，记录内容是语句的原始逻辑
• 用于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 日志之间的逻辑一致问题。