大家好，我是钢板兽！
在上一篇文章中，我分别介绍了 Undo Log、Redo Log 和 Binlog 在事务执行过程中的作用与写入机制。然而，实际应用中，这三种日志的写入是有先后顺序的。因此，本篇文章将深入探讨它们的写入顺序，以便更好地理解三者与事务的联系。
1.涉及的关键缓存
在事务执行过程中，涉及多个重要的缓存机制，理解这些缓存有助于更清晰地掌握日志的写入顺序：
- Buffer Pool（缓冲池）存储 InnoDB 数据页的内存缓冲区，事务修改数据页首先在此处完成，修改后的数据页被称为脏页（Dirty Page）。
- Undo Log Buffer（Undo 日志缓存区） 记录事务修改前的数据版本，存储于内存，在特定时机刷新到磁盘的 Undo 表空间。
- Redo Log Buffer（Redo 日志缓存区） 存储事务修改后的数据变化记录（物理日志），位于内存中，在事务提交时强制刷新到磁盘的 Redo 日志文件。
- Binlog Cache（Binlog 缓存区） MySQL Server层的内存缓存，存储事务中修改的数据变化记录（逻辑变化），在事务提交时统一刷入磁盘的 Binlog 文件。
2.事务执行阶段各日志的写入流程
事务可以分为两个阶段：事务执行阶段和事务提交阶段，假设我们有一个更新事务的SQL语句：
UPDATE account SET balance = balance - 100 WHERE id = 1;
我们先来看看事务执行阶段各日志的写入流程：
（1）数据页加载到buffer pool：从磁盘中加载数据页到buffer pool；
（1）写入Undo Log Buffer：先把待修改数据的原始版本（例如 balance=1000）记录到内存中的 Undo Log Buffer 中。
- 这个 Undo Log Buffer 会在合适时机（后台线程）异步刷新到磁盘（Undo 表空间）。
（3）数据页（脏页）的修改：事务修改内存中的数据页（buffer pool），修改后的数据页变为脏页（Dirty Page），等待后台线程（如checkpoint）异步刷新到磁盘上的表空间文件（.ibd 文件）。
（4）写入Redo Log Buffer：数据库会把修改后的数据记录（例如：balance=900）记录到内存中的 Redo Log Buffer 中。
- Redo Log Buffer 会在以下几种情况下被刷新到磁盘（Redo Log File）：
- 事务提交时；
- Redo Log Buffer 达到指定阈值；
- 后台线程定期刷新。
（5）写入Binlog Cache：把SQL语句逻辑记录到内存中的Binlog Cache。
到这里为止（事务未提交阶段），此时的日志情况为：
- Undo Log Buffer 已写入旧版本数据；
- Redo Log Buffer 中包含数据修改后的版本记录；
- Buffer Pool 中的数据页被真正修改，处于内存脏页状态。
- Binlog Cache中包含此次修改的SQL语句逻辑。
3.事务提交阶段
事务提交采用两阶段提交（2PC）机制：Prepare阶段（半提交状态）和Commit阶段（已提交状态），
（1）Prepare状态：InnoDB 存储引擎将 Redo Log Buffer 中的日志记录强制刷入磁盘上的 Redo Log File（调用 write 和 fsync），Undo Log也是同样的过程。
- 此时Redo Log 已持久化，但 Binlog 尚未刷入磁盘。
（2）MySQL层将 Binlog Cache 中的日志记录刷新到磁盘中的Binlog文件（调用 write 和 fsync）。
（3）Commit状态：执行器调用InnoDB存储引擎的提交事务接口，将刚刚写入的Redo Log改成Commit状态
4.为什么要两阶段提交？
这里的两阶段提交主要是针对Redo Log和Binlog来说的，为什么不能是先写Redo Log 后写binlog，或者先写binlog 后写Redo Log就完事儿了呢，还要从中多出一个“Prepare状态”？
（1）假设是先写Redo Log，后写binlog。向表中插入一条数据R，当redolog写入完成，但是binlog还没写时，就出现了宕机.那么主机崩溃恢复时，redolog中是有记录R的，但是从机根据binlog进行主从同步时，从机是没有数据R，就会出现主从数据不一致的问题。
（2）假设先写 binlog 再写 redolog 。向表中插入一条记录 R，先写 binlog 再写 redolog，当binlog写入完成，但是redolog还没写时，就出现了宕机，那么从机根据binlog进行主从同步时，从机是有数据R的。但是主机崩溃恢复时，redolog中是没有记录R的，就会出现主从数据不一致的问题。
但是现在“两阶段提交”，我们再来看几种情况：
（1）一阶段提交之后崩溃了，即写入 redo log，处于 prepare 状态的时候崩溃了，此时，由于 binlog 还没写，redo log 处于 prepare 状态还没提交，所以崩溃恢复的时候，这个事务会根据undolog来回滚，此时 binlog 还没写，所以也不会传到备库。
（2）写完 binlog 之后崩溃了，此时：redolog 中的日志处于 prepare 状态，还没有提交，那么恢复的时候，首先检查 binlog 中的事务是否存在并且完整，如果存在且完整，则直接提交事务，如果不存在或者不完整，则回滚事务。
（3）假设 redolog 处于 Commit 状态的时候崩溃了，那么重启后的处理方案同情况二。
最后，我们来画图总结一下三种日志在事务过程中的写入顺序：
5.三种日志写入的参数
这里总结一下三种日志的写入过程涉及到的参数变量，可以了解一下。
（1）Redo Log的参数
| 参数 | 作用 |
|---|---|
innodb_log_file_size | 单个 redo log 文件的大小（影响崩溃恢复速度）。 |
innodb_log_files_in_group | redo log 文件数量，默认 2，日志总大小 = innodb_log_file_size × innodb_log_files_in_group。 |
innodb_flush_log_at_trx_commit | 控制 redo log 刷盘策略，取值： 0：每秒刷盘一次（可能丢失 1 秒数据） 1（默认）：每次事务提交时写入并刷盘（最安全） 2：每次事务提交时写入 OS 缓存，但不刷盘（可能丢数据） |
innodb_log_buffer_size | redo log 缓冲区大小，事务提交时才刷盘，缓冲区满了也会刷。 |
（2）Binlog的参数
| 参数 | 作用 |
|---|---|
log_bin | 是否开启 binlog，默认关闭，主从复制和 Point-In-Time 恢复必须开启。 |
binlog_format | binlog 记录格式，取值： STATEMENT（SQL 语句级别，可能有副作用） ROW（记录数据变更，推荐） MIXED（两者结合） |
sync_binlog | 控制 binlog 刷盘策略，取值： 0：操作系统决定何时刷盘（可能丢数据） 1（默认）：每次事务提交时刷盘（最安全） >1：每 N 个事务刷一次盘，性能较好但风险增加 |
max_binlog_size | 单个 binlog 文件的大小，超过该值后生成新 binlog（默认 1GB）。 |
expire_logs_days | binlog 自动清理天数，如 7 表示 7 天后自动删除。 |
（3）Undo Log的参数
关键参数：
| 参数 | 作用 |
|---|---|
innodb_undo_tablespaces | undo log 独立表空间数量，默认 0，表示undo log全部写入一个表空间文件，可以设置这个变量，平均分配到多少个文件中. |
innodb_undo_log_truncate | 是否允许 undo log 触发在线回收机制，默认 1，可防止 undo log 过大。 |
innodb_max_undo_log_size | undo log 触发 truncate 的阈值（默认 1GB）。 |
innodb_undo_logs | 事务可以同时使用的回滚段数量（默认 128）。 |
通过本篇文章的讲解，相信大家对 Undo Log、Redo Log 和 Binlog 的写入顺序及其重要性有了更深入的理解。如果这篇文章对你有所帮助，欢迎点赞、转发、留言！
