MySQL数据库作为一个主流数据库，对于意外宕机的情况下，数据的一致性和完整性，必须要有保障，那么具体是怎么保障的呢。
对于数据的完整性保障，MySQL的架构中，这个任务取决于具体的存储引擎。
- 像MyISAM这类的存储引擎，没有事务支持，并不能很好的保证数据的完整性。如果突然断电，则可能会出现数据文件损坏，此时需要用通过mysiamchk工具来进行修复。
- 像Memory这类更为简单的存储引擎，掉电数据就没有了，只能人为介入，重新恢复
- 像InnoDB这样比较高级的存储引擎，数据的一致性和完整性的保存，已经设计的比较完备了，可以在各种意外崩溃情况发生下保证数据的一致性。是通过以下几个技术来实现的。
WAL（ Write-Ahead Logging）
这是InnoDB使用的重要的数据一致性保证的技术之一，即先写日志，假设我们更新A表中的某一行数据，MySQL会将这个操作作为一个日志记录在名为Redo Log的日志中，然后更新内存数据块，并不要求马上更新数据表磁盘文件，会在合适的时候再把内存中的数据块刷新到磁盘上。
这样的好处是把对磁盘的随机访问，变成了顺序访问，提高了效率。
Redo Log
正如刚才所讲，Redo Log中记录了执行的数据库操作。具体来讲，Redo Log 有内存中的Redo Log Buffer 和磁盘中的 Redo Log File，数据库操作会先写入到内存中的Redo Log Buffer中，一旦Redo Log Buffer 写满，或者事务提交了，就需要把Redo Log buffer写入到 Redo Log File中持久化储存起来
Undo Log
Undo Log是和和数据库操作的反向操作，进行一次数据库修改就会产生一组对应的Undo Log 用来回滚数据操作和实现MySQL的多版本控制MVCC。Undo Log的产生也会产升Redo Log，所以他的持久化是可以通过Redo Log来保证的。
崩溃恢复
如果一个InnoDB数据库处于意外停止的情况下，他会怎样恢复呢，InnoDB会首先重放所有磁盘中的Redo Log。这是会将数据文件更新到尽可能最新的状态（包括所有未回滚的事务），同时一会把Undo Log初始化到崩溃前的状态（由于Undo Log受Redo Log保护），最后再将所有为未提交的事务用Undo Log回滚。这样，数据库就处于一个最新的且数据一致的状态了。
