InnoDB 中 redo log 和 undo log 以及数据页的修改顺序到底是怎样的？

[Marathonk]

一个事务提交后，为了保证事务的原子性与持久性，会在 undo log 和 redo log 记录相应的日志，以在需要回滚或重做时使用。但是目前关于 redo log 和 undo log 以及数据页的写入顺序并没有找到解释的清楚的资料。

林晓斌写的是“引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面”，这个同时能保证是原子的吗，是不是从 数据更新到内存 到 写 undo log 和 redo log 完成这段时间里，数据页是不会作为脏页刷入磁盘的（或者说 是不会写到 buffer pool 的 flush 链表中的）？

[Marathonk]

MySQL 中的 Undo Log 严格的讲不是 Log ，而是数据，因此他的管理和落盘都跟数据是一样的：
Undo 的磁盘结构并不是顺序的，而是像数据一样按 Page 管理 Undo 写入时，也像数据一样产生对应的 Redo Log
Undo 的 Page 也像数据一样缓存在 Buffer Pool 中，跟数据 Page 一起做 LRU 换入换出，以及刷脏。
Undo Page 的刷脏也像数据一样要等到对应的 Redo Log 落盘之后

之所以这样实现，首要的原因是 MySQL 中的 Undo Log 不只是承担 Crash Recovery 时保证 Atomic 的作用，更需要承担 MVCC 对历史版本的管理的作用，设计目标是高事务并发，方便的管理和维护。因此当做数据更合适。

但既然还叫 Log ，就还是需要有 Undo Log 的责任，那就是保证 Crash Recovery 时，如果看到数据的修改，一定要能看到其对应 Undo 的修改，这样才有机会通过事务的回滚保证 Crash Atomic 。标准的 Undo Log 这一步是靠 WAL 实现的，也就是要求 Undo 写入先于数据落盘。而 InnoDB 中 Undo Log 作为一种特殊的数据，这一步是通过 redo 的 min-transaction 保证的，简单的说就是数据的修改和对应的 Undo 修改，他们所对应的 redo log 被放到同一个 min-transaction 中，同一个 min-transaction 中的所有 redo log 在 Crash Recovery 时以一个整体进行重放，要么全部重放，要么全部丢弃。

[liuxingchina]

1.磁盘加载数据到 buffer pool
2.写入 undo log 记录旧数据用于回滚
3.写入 redo log buffer
4.redo log 刷盘
5.写入 bin log
6.写入 commitId 到 redo log
7.事务提交

[Marathonk]

@liuxingchina 其实我之前的主要疑问也在这里，如果 1 完成 2 还没做，同时 buffer pool 中的数据被持久化到磁盘了，这时数据库崩溃了，那岂不是写入了脏数据进来？
后来查阅了很多资料，其实 Innodb 内部实现还是很复杂的，简单的逻辑是会保证 undo log 和数据页的修改都写入 redo log 并且落盘后，前者才会落盘，这也是保证原子性的基础。