前言
说到数据库事务，大家脑子里一定很容易蹦出一堆事务的相关知识，如事务的acid特性，隔离级别，解决的问题（脏读，不可重复读，幻读）等等，但是可能很少有人真正的清楚事务的这些特性又是怎么实现的，为什么要有四个隔离级别。
在之前的文章我们已经了解了mysql中事务的隔离性的实现原理，今天就继续来聊一聊mysql持久性的实现原理。
当然mysql博大精深，文章疏漏之处在所难免，欢迎批评指正。
说明
mysql的事务实现逻辑是位于引擎层的，并且不是所有的引擎都支持事务的，下面的说明都是以innodb引擎为基准。
innodb读写数据原理
在往下学习之前，我们需要先来了解下innodb是怎么来读写数据的。我们知道数据库的数据都是存放在磁盘中的，然后我们也知道磁盘i/o的成本是很大的，如果每次读写数据都要访问磁盘，数据库的效率就会非常低。为了解决这个问题，innodb提供了 buffer pool 作为访问数据库数据的缓冲。
buffer pool 是位于内存的，包含了磁盘中部分数据页的映射。当需要读取数据时，innodb会首先尝试从buffer pool中读取，读取不到的话就会从磁盘读取后放入buffer pool；当写入数据时，会先写入buffer pool的页面，并把这样的页面标记为dirty，并放到专门的flush list上，这些修改的数据页会在后续某个时刻被刷新到磁盘中（这一过程称为刷脏，由其他后台线程负责） 。如下图所示：
这样设计的好处是可以把大量的磁盘i/o转成内存读写，并且把对一个页面的多次修改merge成一次i/o操作（刷脏一次刷入整个页面），避免每次读写操作都访问磁盘，从而大大提升了数据库的性能。
持久性定义
持久性是指事务一旦提交，它对数据库的改变就应该是永久性的，接下来的其他操作或故障不应该对本次事务的修改有任何影响。
通过前面的介绍，我们知道innodb使用 buffer pool 来提高读写的性能。但是 buffer pool 是在内存的，是易失性的，如果一个事务提交了事务后，mysql突然宕机，且此时buffer pool中修改的数据还没有刷新到磁盘中的话，就会导致数据的丢失，事务的持久性就无法保证。
为了解决这个问题，innodb引入了 redo log来实现数据修改的持久化。当数据修改时，innodb除了修改buffer pool中的数据，还会在redo log 记录这次操作，并保证redo log早于对应的页面落盘（一般在事务提交的时候），也就是常说的wal。若mysql突然宕机了且还没有把数据刷回磁盘，重启后，mysql会通过已经写入磁盘的redo log来恢复没有被刷新到磁盘的数据页。
实现原理：redo log
为了提高性能，和数据页类似，redo log 也包括两部分：一是内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该部分日志是持久的。redo log是物理日志，记录的是数据库中物理页的情况 。
当数据发生修改时，innodb不仅会修改buffer pool中的数据，也会在redo log buffer记录这次操作；当事务提交时，会对redo log buffer进行刷盘，记录到redo log file中。如果mysql宕机，重启时可以读取redo log file中的数据，对数据库进行恢复。这样就不需要每次提交事务都实时进行刷脏了。
写入过程
注意点：
- 先修改buffer pool，后写 redo log buffer。
- redo日志比数据页先写回磁盘：事务提交的时候，会把redo log buffer写入redo log file，写入成功才算提交成功（也有其他场景触发写入，这里就不展开了），而buffer pool的数据由后台线程在后续某个时刻写入磁盘。
- 刷脏的时候一定会保证对应的redo log已经落盘了，也即是所谓的wal（预写式日志），否则会有数据丢失的可能性。
好处
事务提交的时候，写入redo log 相比于直接刷脏的好处主要有三点：
刷脏是随机i/o，但写redo log 是顺序i/o，顺序i/o可比随机i/o快多了，不需要。
刷脏是以数据页（page）为单位的，即使一个page只有一点点修改也要整页写入；而redo log中只包含真正被修改的部分，数据量非常小，无效io大大减少。
刷脏的时候可能要刷很多页的数据，无法保证原子性（例如只写了一部分数据就失败了），而redo log buffer 向 redo log file 写log block，是按512个字节，也就是一个扇区的大小进行写入，扇区是写入的最小单位，因此可以保证写入是必定成功的。
先写redo log还是先修改数据
一次dml可能涉及到数据的修改和redo log的记录，那它们的执行顺序是怎么样的呢？网上的文章有的说先修改数据，后记录redo log，有的说先记录redo log，后改数据，那真实的情况是如何呢？
首先通过上面的说明我们知道，redo log buffer在事务提交的时候就会写入redo log file的，而刷脏则是在后续的某个时刻，所以可以确定的是先记录redo log，后修改data page（wal当然是日志先写啦）。
那接下来的问题就是先写redo log buffer还是先修改buffer pool了。要了解这个问题，我们先要了解innodb中，一次dml的执行过程是怎么样的。一次dml的执行过程涉及了数据的修改，加锁，解锁，redo log的记录和undo log的记录等，也是需要保证原子性的，而innodb通过mtr(mini-transactions)来保证一次dml操作的原子性。
首先来看mtr的定义:
an internal phase of innodb processing, when making changes at the physical level to internal data structures during dml operations. a mini-transactions (mtr) has no notion of rollback; multiple mini-transactionss can occur within a single transaction. mini-transactionss write information to the redo log that is used during crash recovery. a mini-transactions can also happen outside the context of a regular transaction, for example during purge processing by background threads. 见
mtr 是一个短原子操作，不能回滚，因为它本身就是原子的。数据页的变更必须通过mtr，mtr 会把dml操作对数据页的修改记录到 redo log里。
下面来简单看下mtr的过程：
- mtr初始化的时候会初始化一份 mtr_buf
- 当修改数据时，在对内存buffer pool中的页面进行修改的同时，还会生成redo log record，保存在mtr_buf中。
- 在执行mtr_commit函数提交本mtr的时候，会将mtr_buf中的redo log record更新到redo log buffer中，同时将脏页添加到flush list，供后续刷脏使用。在log buffer中，每接收到496字节的log record，就将这组log record包装一个12字节的block header和一个4字节的block tailer，成为一个512字节的log block，方便刷盘的时候对齐512字节刷盘。
由此可见，innodb是先修改buffer pool，后写redo log buffer的。
恢复数据的过程
在任何情况下，innodb启动时都会尝试执行recovery操作。在恢复过程中，需要redo log参与，而如果还开启了binlog，那就还需要binlog、undo log的参与。因为有可能数据已经写入binlog了，但是redo log还没有刷盘的时候数据库就奔溃了（事务是innodb引擎的特性，修改了数据不一定提交了，而binlog是mysql服务层的特性，修改数据就会记录了），这时候就需要redo log，binlog和undo log三者的参与来判断是否有还没提交的事务，未提交的事务进行回滚或者提交操作。
下面来简单说下仅利用redo log恢复数据的过程：
- 启动innodb时，找到最近一次checkpoint的位置，利用checkpoint lsn去找大于该lsn的redo log进行日志恢复。
- 如果中间恢复失败了也没影响，再次恢复的时候还是从上次保存成功的checkpoint的位置继续恢复。
recover过程：故障恢复包含三个阶段：analysis，redo和undo。analysis阶段的任务主要是利用checkpoint及log中的信息确认后续redo和undo阶段的操作范围，通过log修正checkpoint中记录的dirty page集合信息，并用其中涉及最小的lsn位置作为下一步redo的开始位置redolsn。同时修正checkpoint中记录的活跃事务集合（未提交事务），作为undo过程的回滚对象；redo阶段从analysis获得的redolsn出发，重放所有的log中的redo内容，注意这里也包含了未commit事务；最后undo阶段对所有未提交事务利用undo信息进行回滚，通过log的prevlsn可以顺序找到事务所有需要回滚的修改。具体见
什么是lsn?
lsn也就是log sequence number，也日志的序列号，是一个单调递增的64位无符号整数。redo log和数据页都保存着lsn，可以用作数据恢复的依据。lsn更大的表示所引用的日志记录所描述的变化发生在更后面。
什么是checkpoint？
checkpoint表示一个保存点，在这个点之前的数据页的修改（log lsn<checkpoint lsn）都已经写入磁盘文件了。innodb每次刷盘之后都会记录checkpoint，把最新的redo log lsn 记录到checkpoint lsn 里，方便恢复数据的时候作为起始点的判断。
以上就是详解mysql中事务的持久性实现原理的详细内容，更多关于mysql 事务的持久性的资料请关注www.887551.com其它相关文章！