本文介绍了MySQL的崩溃恢复机制，重点讨论了InnoDB存储引擎中的Redo Log和Undo Log。Redo Log记录事务完成后的数据状态，用于恢复未持久化的更新；Undo Log记录事务开始前的数据状态，用于回滚事务。通过2PC协议确保Redo Log和Binlog在事务提交时的数据一致性，保证崩溃后的数据恢复和一致性。
在之前的文章「简单了解InnoDB底层原理」聊了一下MySQL的Buffer Pool。这里再简单提一嘴，Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。
黑盒下的更新数据流程
当我们查询数据的时候，会先去Buffer Pool中查询。如果Buffer Pool中不存在，存储引擎会先将数据从磁盘加载到Buffer Pool中，然后将数据返回给客户端；同理，当我们更新某个数据的时候，如果这个数据不存在于Buffer Pool，同样会先数据加载进来，然后修改修改内存的数据。被修改过的数据会在之后统一刷入磁盘。
这个过程看似没啥问题，实则不讲武德。假设我们修改Buffer Pool中的数据成功，但是还没来得及将数据刷入磁盘MySQL就挂了怎么办？按照上图的逻辑，此时更新之后的数据只存在于Buffer Pool中，如果此时MySQL宕机了，这部分数据将会永久的丢失；
再者，我更新到一半突然发生错误了，想要回滚到更新之前的版本，该怎么办？那不完犊子吗，连数据持久化的保证、事务回滚都做不到还谈什么崩溃恢复？
Redo Log & Undo Log
而通过MySQL能够实现崩溃恢复的事实来看，MySQL必定实现了某些骚操作。没错，这就是接下来我们要介绍的另外的两个关键功能，Redo L
最低0.47元/天 解锁文章
720
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
