前言

在上一章中我们聊到了事务有四大特性：原子性、一致性、隔离性、持久性。本篇文章就持久性重点聊一下，在高性能MySql一书中，对持久性的定义是：一旦事务提交，则起所做的修改就会永久保存到数据库中，此时即使数据库或系统崩溃，修改的数据也不会丢失。
持久性这个概念有点模糊，因为实际上持久性也是分很多种不同的级别的，有些持久性策略能够提供很强的安全保障，有些则未必，并且不可能有能做到100%安全保障的持久性策略，下面我们逐步展开MySQL种事务持久性的真正含义。

ps:基于innodb存储引擎

一、架构图

首先通过几张图片宏观上了解MySQL和innodb的架构

1、MySQL架构图

mysql

2、InnoDB架构图

通过以下两张innodb的架构图可以一目了然的看到innodb数据落盘过程
InnoDB架构图 innodb存储结构图

二、落盘分析

本节是将MySQL落盘过程由浅到深，由简单到复杂逐步分析，来达到理解落盘过程的目的。
落盘1
落盘2

1.第一阶段

假设此时MySQL修改数据后直接写入磁盘，就会有一个问题，数据写入磁盘时随机写的，性能极差，于是有了第二阶段。

2.第二阶段

此阶段增加了缓存这一步，即MySQL修改数据后保存在缓存中，然后由后台线程异步写入磁盘，这个过程也有一个明显的问题，当数据还在缓存中尚未写入磁盘时系统崩溃，会导致数据丢失，安全级别相当差，于是有了第三阶段。

3.第三阶段

此阶段增加了redo log,即更新缓存后，并且同步将redo log写入磁盘，由于redo log是顺序写词盘，所以效率也并不低。这时遇到数据还在缓存中尚未写入磁盘时系统崩溃的情况，MySQL重启是可以根据redo log的内容进行落盘。
但是此时会有脏读，不可重复读等问题，破坏了事务的隔离性。比如A事务更新了缓存但事务尚未提交，B事务去读就会读取到A事务的更新。
这个时候可能有人问了，那A事务更新的时候锁定数据不让B事务读可以吗？可以是可以，但是会导致读性能太差。于是有了第四阶段。

4.第四阶段

此阶段增加了undo log,即在更新缓存前先把对应的反向逻辑日志写到undo log buffer,这样B事务读取事务读取历史版本即可(MVCC机制）。
但是仔细一想还是有问题，那就是MySQL数据落盘是以页为单位的，其大小是16KB,而操作系统的页大小是4KB,如果在落盘的时候操作系统写了12KB时崩溃了，咋办？还有4KB数据呢（这种情况被称为部分写失效），这种情况下MySQL重启如何恢复？？
可能有些同学会想通过redo log来恢复，这是不行的，因为redo log记录的是对页的物理操作，如偏移量800，写’aaa’记录,所以redo log生效的前提必须是MySQL数据页是完整的（姜承尧.MySQL技术内幕:InnoDB存储引擎）。
此时在MySQL崩溃重启恢复应用redo log前，需要一个页的副本，当发生部分写失效时，先通过该页的副本来还原该页后再应用redo log,这里所谓的页副本，这种策略就是double write。于是有了第五阶段。

PS:关于undo log落盘
用户定义的临时表的 undo log不刷盘，非临时表的undo log要刷盘的，undo log记录了事务修改前逻辑日志，本质上是数据，和正常表区别不大，它的内容除了记录到undo tablespaces,也会被记录到redo log。其中刷盘到undo tablespaces的机制和正常表数据一致（异步刷盘），刷盘到redo log的机制是和该undo log其对应的redo log一起刷盘的。

5.第五阶段

此阶段增加了double write buffer,先将缓存中的数据搬到该缓冲区，再刷到共享表空间和各个独立表空间，细节如下：

double write由两部分组成，一部分是内存中的double write buffer，大小为2MB，另一部分是物理磁盘上共享表空间中连续的128个页，即2个区（extent），大小同样为2MB。在对缓冲池的脏页进行刷新时，并不直接写磁盘，而是会通过memcpy函数将脏页先复制到内存中的double write buffer，之后通过double write buffer再分两次，每次1MB顺序地写入共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘，避免缓冲写带来的问题。在这个过程中，因为double write页是连续的，因此这个过程是顺序写的，开销并不是很大。在完成double write页的写入后，再将double write buffer中的页写入各个表空间文件中，此时的写入则是随机的，开销大。

这样就完美解决了部分写失效问题，即使写共享表空间失败，因为还没有写独立表空间，此时直接通过redo log恢复即可，如果写共享表空间成功，写独立表空间部分失败，先通过共享表空间的副本页恢复，再通过redo log恢复。