事务的原子性：事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。
事务的持久性：事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。
undo log：为了实现事务的原子性，在innodb中，还用undo log实现MVCC
undo log原理：在操作任何数据之前，首先将数据备份到一个地方(即undo log)，然后进行数据修改，如果出现错误或用户执行了rollback语句，则系统就可以利用undo log中的备份数据恢复到事务开始之前的状态
redo log原理：redo log记录的是新数据的备份。在事务提交前，只要将redo log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是redo log已持久化，系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。
undo +redo 事务的特点：
1.为了保证持久性，必须在事务提交前将redo 持久化
2.数据不需要在事务提交前写入磁盘，而是缓存在内存中
3.redo 保证事务的持久性
4.undo 保证事务的原子性
5.数据必须要晚于redo log写入持久存储
undo+redo主要是为了提升IO性能，通过缓存数据，减少了写数据的IO。但是却引入了redo log 的IO，通过以下特点提升redo log的IO性能：
1.尽量保持redo log存储在一段连续的空间上，所以在系统第一次启动时就会将日志文件的空间完全分配
2.批量写入日志，引入了redo log buffer，先写入redo log buffer.当需要将日志刷新到磁盘时
3.并发的事务共享redo log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起， 以减少日志占用的空间。
4.当一个事务将Redo Log写入磁盘时，也会将其他未提交的事务的日志写入磁盘。
5.Redo Log上只进行顺序追加的操作，当一个事务需要回滚时，它的Redo Log记录也不会从Redo Log中删除掉。
恢复(recovery)
未提交的事务和回滚了的事务也会记录redo log，因此进行恢复时，这些事务要进行特殊的处理
恢复的策略：
1.进行恢复时，只重做已经提交了的事务
2.进行恢复时，重做所有事务包括未提交的事务和回滚了的事务，然后通过undo log回滚那些未提交的事务
mysql中innodb使用了2的恢复策略，恢复机制有如下特点：
1.在重做redo log时，并不关心事务性。即恢复时，没有BEGIN，也没有COMMIT,ROLLBACK的行为。也不关心每个日志是哪个事务的。尽管事务ID等事务相关的内容会记入Redo Log，这些内容只是被当作要操作的数据的一部分。
2.使用2策略必须将undo log 持久化，且必须要在写redo log之前将对应的undo log写入磁盘，innodb将undo log看做数据，因此记录undo log的操作也会记录到redo log中，这样undo log就可以像数据一样缓存起来，而不用在redo log之前写入磁盘
3.一个回滚了的事务在恢复时的操作就是先redo再undo，
物理的日志(Physical Log)
A. 记录完整的Page
B. 记录Page中被修改的部分(page中的偏移,内容和长度).
优点：不需要持久化的数据保持在一个一致的状态。如：在写一个页面到磁盘上时，系统发生故障，页面上的一部数据写入了磁盘，另一部分丢失了。 这时仍然可以恢复出正确的数据。
缺点：记录的内容很多，占用很大的空间
逻辑的日志(Logical Log)
记录在关系(表)上的一个元组操作。
A. 插入一行记录。
B. 修改一行记录。
C. 删除一行记录。
逻辑日志比起物理的日志，更简洁且占用空间更小。
逻辑日志的缺点：
1.部分执行；如：表T有2个索引，在向T插入1条记录时，需要分别向2个B-Tree中插入记录。 有可能第一个B-Tree插入成功了，但是第二个B-Tree没有插入成功。在恢复或回滚时，需要处理这些特殊情况。
2.操作的一致性问题； 一个插入操作有一个B-Tree的分裂，页A的一半数据移到了B页，A页写入了磁盘，B页没有写入磁盘。如果这时候发生了故障，需要进行恢复，逻辑日志是很难搞定的。
逻辑和物理结合的日志
1.物理到page. 将操作细分到页级别。为每个页上的操作单独记日志。如：一个Insert分别在2个B-Tree的节点上做了插入操作，那么就分别为每一个页的操作记录一条日志。
2.Page内采用逻辑的日志。如：对一个B-Tree的页内插入一条记录时，Page内的逻辑日志只记录：‘这是一个插入操作’和’这行数据的内容‘。
redo log记录是物理和逻辑相结合的日志
1.部分执行是不存在的，因整个页面的操作是原子性的，
2.数据一致性问题仍然存在，通过double write来解决
undo log记录的是逻辑的日志
double write
1.在覆盖磁盘上的数据前，先将Page的内容写入到磁盘上的doublewrite buffer（不是内存空间，是持久存储上的空间)
2.然后再将Page的内容覆盖到磁盘上原来的数据。
如果在1步骤时系统故障，原来的数据没有被覆盖，还是完整的。
如果在2步骤时系统故障，原来的数据不完整了，但是新数据已经被完整的写入了doublewrite buffer. 因此系统恢复时就可以用doublewrite buffer中的新Page来覆盖这个不完整的page.
double write的特点：
1.Double write buffer是一段连续的存储空间，可以顺序写入。
2. Double write有自己的写buffer.
3. 先将多个要做doublewrite的page写入内存的buffer，然后再一起写到磁盘上
checksum
检测页面是否一致。每个页面修改完成后都会计算一个页面的checksum。这个checksum存放在页面的尾部.每次从磁盘读一个页到内存时，都需要检测页的一致性。
checkpoint
随着时间的积累，Redo Log会变的很大很大。如果每次都从第一条记录开始恢复，恢复的过程就会很慢。为了减少恢复的时间，就引入了Checkpoint机制。
checkpoint原理：在某个时间点，所有的脏页都被刷新到了磁盘上.这个时间点之前的所有Redo Log就不需要重做了。系统记录下这个时间点时redo log的结尾位置作为checkpoint. 在进行恢复时，从这个checkpoint的位置开始即可。Checkpoint点之前的日志也就不再需要了，可以被删除掉。为了更好的利用日志空间，InnoDB以环形缓存(circular buffer)的方式来使用日志空间。
sharp checkpoint
在某个时间开始停止一切更新操作，直到所有的脏页被刷新到磁盘，Checkpoint被记录。 显然对于繁忙的系统, 这种方法是不合适的。
Sharp checkpoint完成时，持久存储中存储的数据是某个确切时间点的内存数据的快照。
fuzzy checkpoint
刷脏页的同时用户还在更新数据，LSN1前的某个脏页在刷到持久存储之前就有可能被
LSN1之后的某个操作给修改了。当checkpoint完成时，LSN1后的部分操作(R1,R2对应的操作)也被 持久化了。
说明：checkpoint 在LSN1位置，当checkpoint完成时R1,R2对应的修改也被刷到了持久存储。
恢复时要从LSN1位置开始，包括R1, R2在内。
Fuzzy checkpoint完成时，持久存储中存储的数据不是某个确切时间点的内存数据的快照。
脏页(dirty page)
如果一个数据页在内存中修改了，但是还没有刷新到磁盘。这个数据页就称作脏页。
日志顺序号(Log Sequence Number)
LSN是日志空间中每条日志的结束点，用字节偏移量来表示。在Checkpoint和恢复时使用。
数据页的最新LSN
InnoDB中每个数据页上都记录有一个LSN。每次更新数据页时，将LSN修改为当前操作的redo log的LSN。在恢复时，如果数据页的LSN大于等于当前redo log的LSN，则跳过此日志。
异步checkpoint
实现了幂等规则后，脏页就可以在任何时间，以任何顺序写入持久存储了。InnoDB的buffer pool有 一套单独的机制来刷脏页。因此很多情况下checkpoint时，并不写脏页到存储。只是将所有脏页的最小的LSN记做checkpoint.
同步checkpoint
InnoDB的buffer pool通过LRU的算法来决定哪些脏页应该被写入持久存储。如果包含最小LSN的页面频繁的被更新，它就不会被刷到存储上。这样就可能导致checkpoint点很长一段时间无法前进,甚至导致日志空间被占满。这时就要按照LSN由最小到大的顺序写一部分脏页到持久储。
译者介绍：家华，从事mysqlDBA的工作，记录自己对mysql的一些总结