1. 背景
MySQL实现事务、崩溃恢复、集群的主从复制，底层都离不开日志，所以日志是MySQL的精华所在。只有了解MySQL日志，才算是彻底搞懂MySQL。
今天一灯就带你深入浅出的学习MySQL的三大日志系统，Redo Log（重做日志）、Undo Log（恢复日志）、Bin Log（备份日志）。
2. Redo Log（重做日志）
2.1 Redo Log的内容与作用
Redo Log 记录的是物理日志，也就是磁盘数据页的修改。
作用： 用来保证服务崩溃后，仍能把事务中变更的数据持久化到磁盘上。
MySQL事务中持久性就是使用Redo Log实现的。
2.2 什么时候写入Redo Log？
- 从磁盘加载数据到内存
- 在内存中修改数据
- 把新数据写到Redo Log Buffer中
- 把Redo Log Buffer中数据持久化到Redo Log文件中
- 把Redo Log文件中数据持久化到数据库磁盘中
你可能会问，为什么需要写Redo Log Buffer和Redo Log FIle？直接持久化到磁盘不好吗？
直接写磁盘会有产生严重的性能问题：
-
InnoDB在磁盘中存储的基本单元是页，可能本次修改只变更一页中几个字节，但是需要刷新整页的数据，就很浪费资源。
-
一个事务可能修改了多页中的数据，页之间又是不连续的，就会产生随机IO，性能更差。
这种方案叫做WAL（Write-Ahead Logging），预写日志，就是先写日志，再写磁盘。
2.3 Redo Log刷盘规则
写入Redo Log Buffer之后，并不会立即持久化到Redo Log FIle，需要等待操作系统调用fsync()操作，才会刷到磁盘上。
具体什么时候可以把Redo Log Buffer刷到Redo Log FIle中，可以通过innodb_flush_log_at_trx_commit参数配置决定。
| 参数值 | 含义 |
|---|---|
| 0（延迟写） | 提交事务后，不会立即刷到OS Buffer中，而是等一秒后刷新到OS Buffer并调用fsync()写入Redo Log FIle，可能会丢失一秒钟的数据。 |
| 1（实时写 | 每次提交事务，都会刷新到OS Buffer并调用fsync()写到Redo Log FIle，性能较差 |
| 2（延迟刷新） | 每次提交事务只刷新到OS Buffer，一秒后再调用fsync()写入Redo Log FIle。 |
InnoDB 的Redo Log File是固定大小的。可以配置为每组4个文件，每个文件的大小是 1GB，那么Redo Log File可以记录4GB的操作。
采用循环写入覆盖的方式，write pos记录开始写的位置，向后移动。checkpoint记录将要擦除的位置，也是向后移动。write pos到checkpoint之间的位置，是可写区域，checkpoint到write pos之间的位置是已写区域。
3. Undo Log（回滚日志）
3.1 Undo Log的内容与作用
Undo Log记录的是逻辑日志，也就是SQL语句。
比如：当我们执行一条insert语句时，Undo Log就记录一条相反的delete语句。
作用：
-
回滚事务时，恢复到修改前的数据。
-
实现 MVCC（多版本并发控制，Multi-Version Concurrency Control） 。
MySQL事务中原子性就是使用Undo Log实现的。
3.2 Undo Log如何回滚到上一个版本
实现方式通过两个隐藏列trx_id（最近一次提交事务的ID）和roll_pointer（上个版本的地址），建立一个版本链。并在事务中读取的时候生成一个ReadView（读视图），在Read Committed隔离级别下，每次读取都会生成一个读视图，而在Repeatable Read隔离级别下，只会在第一次读取时生成一个读视图。
4. Bin Log（备份日志）
4.1 Bin Log的内容与作用
Bin Log记录的是逻辑日志，即原始的SQL语句，是MySQL自带的。
作用： 数据备份和主从同步。
Bin Log共有三种日志格式，可以binlog_format配置参数指定。
| 参数值 | 含义 |
|---|---|
| Statement | 记录原始SQL语句，会导致更新时间与原库不一致。 比如 update_time=now() |
| Row | 记录每行数据的变化，保证了数据与原库一致，缺点是数据量较大。 |
| Mixed | Statement和Row的混合模式，默认采用Statement模式，涉及日期、函数相关的时候采用Row模式，既减少了数据量，又保证了数据一致性。 |
4.2 什么时候写入Bin Log？
Bin Log采用追加写入的模式，并不会覆盖原有日志，所以可以用来恢复到之前某个时刻的数据。
Bin Log也是采用WAL模式，先写日志，再写磁盘。
至于什么时候刷新到磁盘，可以sync_binlog配置参数指定。
| 参数值 | 含义 |
|---|---|
| 0（延迟写） | 每次提交事务都不会刷盘，由系统自己决定什么时候刷盘，可能会丢失数据。 |
| 1（实时写） | 每次提交事务，都会刷盘，性能较差。 |
| N（延迟写） | 提交N个事务后，才会刷盘。 |
加入写Bin Log之后的事务流程：
这就是二阶段提交的概念，先写处于prepare状态的Redo Log，事务提交后，再写处于commit状态的Redo Log。
知识点总结：
有了MySQL日志的基础，下篇就可以一块学习MySQL集群和主从同步了。
推荐阅读：
为什么要用MQ？MQ的作用有哪些？
高并发场景下，如何保证数据的一致性的？
如何进行分库分表？分库分表后有哪些问题以及对应的解决方案。
高并发下怎么生成订单ID？以及每种方案的优缺点。
如何实现分布式锁？使用数据库、分布式数据库、分布式协调服务分别如何实现？
MySQL索引底层数据结构为什么要用B+树？以及红黑树、B树的优缺点。
ThreadLocal线上故障复盘，差点丢了工作。
一篇文章讲清楚MySQL的聚簇/联合/覆盖索引、回表、索引下推
MySQL事务底层原理
MySQL update语句加锁过程和原理
文章持续更新，可以微信搜一搜「 一灯架构 」第一时间阅读更多技术干货。
