事务是指构成单一逻辑工作单元的操作的集合。数据库系统维护事务的ACID四个特性：
- 原子性：事务的所有操作在数据库中要么全部反映，要么全部不反映。
- 一致性：事务执行前后数据库保持约束一致性和业务逻辑一致性。
- 隔离性：在事务并发执行时，各个事务都感觉不到其他事务的存在。
- 持久性：事务一旦提交，其更改是永久性的，即使数据库系统崩溃也能恢复。
先从持久性说起。
持久性
保证持久性的策略就是Write Ahead Logging。在事务提交之前，备份一份事务的操作日志在磁盘上，备份成功再允许事务成功提交。
InnoDB引擎中支持持久性的是redo log，redo log写入过程如图所示：
redo log的写入为顺序循环写入。默认有两个redo log文件，InnoDB顺序写其中一个，写满之后，再顺序写另外一个日志文件，再回过头来写第一个…循环往复。
既然重复利用redo log文件，就涉及到确定哪些日志可以被覆写的问题，InnoDB引擎利用CheckPoint技术来解决这个问题。
CheckPoint
在深入理解InnoDB引擎–存储结构与文件中介绍了LSN记录了页的版本，CheckPoint用以表示已经刷新至磁盘的页的版本，在CheckPoint之前的事务已经持久化在磁盘上，redo log可以被覆写重用。
在事务的执行过程中，由于缓存的缘故，有些页被修改后（脏页）并没有立刻被刷新至磁盘，但是事务提交成功了（redo log已经记录完毕）。
那么什么时候刷新缓存中的脏页到磁盘呢？主要有以下三种情况：
- 周期性刷新：Master Thread周期性刷新一定脏页到磁盘
- 缓存不够用：基于LRU的缓存不够用，需要刷新一定脏页给新的热点页腾出位置
- redo log不够用：checkpoint_age高出async_water_mark/sync_water_mark，刷新一定脏页到磁盘以保证redo log有足够的空间给后来事务覆写
其他问题
redo log文件大小问题
redo log 不能太大也不能太小：redo log日志太大，将会导致大量脏页驻留内存而未被刷新至磁盘，系统故障恢复时将需要更多的时间。redo log日志太小，日志文件切换频率和发生CheckPoint的频率随着升高，导致性能抖动。
redo log写入“深度”
innodb_flush_log_at_trx_commit参数控制着redo log的写入策略：
| 参数值 | commit写入位置 | 性能与可靠性 |
|---|---|---|
| 0 | 内存里的redo log buffer，最终等待Master Thread刷新回磁盘 | 性能最好，可靠性最差，数据库系统故障则发生事务丢失 |
| 1 | 磁盘，调用fsync直接刷新至磁盘 | 性能最差，可靠性最好，不会发生事务丢失 |
| 2 | 磁盘缓存，最终等待宿主机文件系统刷新回磁盘 | 性能中等，可靠性中等，数据库系统故障但是宿主机操作系统不故障则不会发生事务丢失 |
MySQL技术内幕 InnoDB存储引擎 第2版