一条SQL更新语句的执行流程2

3.3 redo日志的系统变量

redo日志位于MySQL数据目录下，默认有ib_logfile0和ib_logfile1两个文件，如下图所示。

可以发现，两个redo日志文件的大小都是50331648，默认48MB。为什么这个大小是固定的呢？因为如果我们要使用顺序I/O，就必须在申请磁盘空间的时候一次性决定申请的空间大小，这样才能保证申请的磁盘空间在地址上的连续性。

这也就决定了redo日志的旧数据会被覆盖，一旦文件被写满，就会触发Buffer Pool脏页到磁盘的同步，以腾出额外空间记录后面的修改。

可以通过以下指令查看redo日志的系统属性。

mysql> show variables like 'innodb_log%';
+-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| innodb_log_buffer_size      | 16777216 |
| innodb_log_checksums        | ON       |
| innodb_log_compressed_pages | ON       |
| innodb_log_file_size        | 50331648 |
| innodb_log_files_in_group   | 2        |
| innodb_log_group_home_dir   | ./       |
| innodb_log_write_ahead_size | 8192     |
+-----------------------------+----------+

介绍到这里，读者朋友可以发现，我们刚才探索的是如何让已经提交的事务保持持久化，但是如果某些事务偏偏在执行到一半的时候出现问题怎么办？

事务的原子性要求事务中的所有操作要么都成功，要么都失败，不允许存在中间状态。就好比我在写这篇文章的时候，会时不时地敲一下ctrl+Z返回到上一步或者过去好几步之前的状态，MySQL也需要“留一手”，把事务回滚时需要的东西都记录下来。

比如，插入数据的时候，至少应该把新增的这条记录的主键的值记录下来，这样回滚的时候只要把这个主键值对应的记录删除就可以了。

MySQL又一个鼎鼎大名的日志—— undo日志 ，正式登场！

4. undo日志

undo log（撤销日志或回滚日志）记录了事务发生之前的数据状态，分为insert undo log和update undo log。

如果修改数据时出现异常，可以用 undo log来实现回滚操作（保持原子性）。可以理解为undo日志记录的是反向的操作，比如INSERT操作会记录DELETE，UPDATE会记录UPDATE之前的值，和redo日志记录在哪个物理页面做了什么操作不同，所以这是一种逻辑格式的日志。

undo日志和redo日志与事务密切相关，被统称为「事务日志」。

关于undo日志，我们目前只需要了解这么多即可

5. SQL更新语句的执行总结——初版

有了事务日志之后，我们来简单总结一下更新操作的流程，这是一个简化的过程。

name 原值是chanmufeng。

update t_user_innodb set name ='chanmufeng1994' where id = 1;

1. 事务开始，从内存（Buffer Pool）或磁盘取到包含这条数据的数据页，返回给 Server 的执行器；
2. Server 的执行器修改数据页的这一行数据的值为 chanmufeng1994；
3. 记录 name=chanmufeng 到undo log；
4. 记录 name=chanmufeng1994到redo log；
5. 调用存储引擎接口，记录数据页到Buffer Pool（修改 name=penyuyan）；
6. 事务提交。

6. binlog日志

之前我们讲过，从MySQL整体架构来看，其实可以分成两部分

• Server 层，它主要做的是 MySQL功能层面的事情，比如处理连接、解析优化等；
• 存储引擎层，负责存储相关的具体事宜。

redo日志是InnoDB存储引擎特有的日志，而Server层也有自己的日志，称为 binlog（归档日志），它可以被所有存储引擎使用。

6.1 为什么有了redo日志还需要 binlog？

我想你可能会问出这个问题，实际上，更准确的问法是为什么有了binlog还需要有redo日志？主要有以下几个原因。

1. 因为最开始MySQL里并没有InnoDB存储引擎。MySQL自带的引擎是MyISAM，但是 MyISAM没有崩溃恢复的能力，InnoDB后来以插件的形式被引入，顺便带来了redo日志；
2. binlog日志是用来归档的，binlog以事件的形式记录了所有的 DDL和 DML 语句（因为它记录的是操作而不是 数据值，属于逻辑日志），但是不具备宕机恢复的功能，因为可能没有来得及刷新脏页，造成脏页数据的丢失，而这些操作也没有保存到binlog中从而造成数据丢失；
3. binlog记录的是关于一个事务的具体操作内容，即该日志是逻辑日志。而redo日志记录的是关于每个页的更改的物理情况。功能压根不是一回事儿。

6.2 binlog日志的作用

6.2.1 主从复制

binlog是实现MySQL主从复制功能的核心组件。

master节点会将所有的写操作记录到binlog中，slave节点会有专门的I/O线程读取master节点的binlog，将写操作同步到当前所在的slave节点。

6.2.2 数据恢复

假如你在阅读这篇文章的时候觉得我写得实在太好，拍案叫绝的时候一不小心把公司的数据库给删了，你该怎么做才能恢复到你删库之前的那个时刻的状态？

这个时候就要用到binlog了，前提是binlog没有被删除，否则，神仙也救不了你了。

通常情况下，公司会定期对数据库进行全量备份，可能隔一个月，一周，甚至可能每天都备份一次。运气好的话你可以使用前一天的全量备份，恢复到前一天的某时刻状态（或者一周、一月之前），然后从全量备份的时刻开始，从binlog中提取该时刻之后（前提是你的binlog里面存放了这段时间的日志）的所有写操作（当然，你得过滤掉你的删库操作），然后进行操作回放就可以了。

是不是很简单？

问题又来了。再看一眼我们的更新语句。

update t_user_innodb set name ='chanmufeng1994' where id = 1;

假如这条更新语句已经被写入到了redo日志，还没来得及写binlog的时候，MySQL宕机重启了，我们看一下会发生什么。

因为redo日志可以在重启的时候用于恢复数据，所以写入磁盘的是chanmufeng1994。但是binlog里面没有记录这个逻辑日志，所以这时候用binlog去恢复数据或者同步到从库，就会出现数据不一致的情况。

所以在写两个日志的情况下，就类似于「分布式事务」的情况，如果你不清楚分布式事务是个什么东西也没关系，我在之后的文章会介绍到。能够明确的就是redo日志和binlog日志如果单纯依次进行提交是无法保证两种日志都写成功或者都写失败的。

我们需要「两阶段提交」。

6.3 两阶段提交

两阶段提交不是MySQL的专利，两阶段提交是一种跨系统维持数据逻辑一致性的常见方案，尤其在分布式事务上，所以请读者重点体会思想

我们把redo日志的提交分成两步，两步中redo日志的状态分别是prepare和commit。步骤如下

1. InnoDB存储引擎将更改更新到内存中后，同时将这个更新操作记录到redo日志里面，此时redo日志处于prepare状态；
2. 执行器生成这个操作的binlog，并将binlog刷盘；
3. 执行器调用InnoDB的提交事务接口，InnoDB把刚刚写入的redo日志改成commit状态。至此，所有操作完成。

加上两阶段提交之后我们再来看一下SQL更新语句的执行流程。

7. SQL更新语句的执行总结——终版

1. 客户端发送更新命令到MySQL服务器，经过处理连接、解析优化等步骤；
2. Server层向InnoDB存储引擎要id=1的这条记录；
3. 存储引擎先从缓存中查找这条记录，有的话直接返回，没有则从磁盘加载到缓存中然后返回；
4. Server层执行器修改这条记录的name字段值；
5. 存储引擎更新修改到内存中；
6. 存储引擎记录redo日志，并将状态设置为prepare状态；
7. 存储引擎通知执行器，修改完毕，可以进行事务提交；
8. Server先写了个binlog；
9. Server提交事务；
10. 存储引擎将redo日志中和当前事务相关的记录状态设置为commit状态。

完！

参考资料

1. MySQL实战45讲
2. MySQL是怎样运行的