Mysql中undolog、redolog、binlog的写入顺序是怎么样的？

InnoDB为了保证ACID的原子性与持久性，需要利用undo log和redo log这两种技术。这两者的写入顺序是：先写undo log，再写redo log。

这是因为：
undo log是用于事务回滚，当一个事务开始时，就需要记录undo log。
redo log是用于保证事务的持久性，在事务提交时写入。
举个例子，当我们要更新一条数据的时候，先在undo log中记录一下这条数据的旧值，以便于发生错误时能将数据恢复。然后修改这条数据的内容，最后在redo log中记录这条数据改变后的新值，以便于数据库崩溃后能从redo log中恢复数据。所以说，undo log是先写的，redo log是后写的。

另外，未提交事务产生的redo日志，如果由于某种原因这个事务回滚，对应的redo不会被清楚但也不会被应用，同样保证了数据的一致性。

update set user_name = '张三' from t_user where id = 1;

1. 执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：
   1. 如果 id=1 这一行所在的数据页本来就在 buffer pool 中，就直接返回给执行器更新；
   2. 如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。
2. 执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：
   1. 如果一样的话就不进行后续更新流程；
   2. 如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作；
3. 开启事务， InnoDB 层更新记录前，首先要记录相应的 undo log，因为这是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存修改该 Undo 页面后，需要记录对应的 redo log。
4. InnoDB 层开始更新记录，会先更新内存（同时标记为脏页），然后将记录写到 redo log 里面，这个时候更新就算完成了。为了减少磁盘I/O，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
   至此，一条记录更新完了。
5. 在一条更新语句执行完成后，然后开始记录该语句对应的 binlog，此时记录的 binlog 会被保存到 binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘。
6. 开始2阶段提交