Marathonk

本科的话，开的足够简单的，留给自己充足的时间玩

@Moha 日，我也是，明年才毕业

@Nasei 试试

@smallyu 仿照做一个吗

@macwk 老哥，为啥 macwk502 了，是出什么事情了吗

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

@koor 一件代发，他们不囤货，不知道货还有没有，只有你下单后他们去让代发商发货时才知道没货了，这时候一般会让你取消订单。淘宝遇到这种会赔百分之几来着，我上次索赔了，然后店铺短信轰炸我了哈哈哈

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 时以一个整体进行重放，要么全部重放，要么全部丢弃。

期待开源，mark 一下