共计 1450 个字符，预计需要花费 4 分钟才能阅读完成。
MySQL 事务的实现涉及到 redo 和 undo 以及 purge，redo 是保证事务的原子性和持久性；undo 是保证事务的一致性（一致性读和多版本并发控制）；purge 清理 undo 表空间
背景知识，对于 Innodb 表中的行每一行包括：
6 字节的事务 ID(DB_TRX_ID)字段: 用来标识最近一次对本行记录做修改 (INSERT|UPDATE) 的事务的标识符, 即最后一次修改 (INSERT|UPDATE) 本行记录的事务 id。
7 字节的回滚指针 (DB_ROLL_PTR) 字段: 指写入回滚段 (ROLLBACK segment) 的 UNDO LOG record (撤销日志记录记录)。
如果一行记录被更新, 则 UNDO LOG record 包含 ‘ 重建该行记录被更新之前内容 ’ 所必须的信息。
1，MySQL 事务执行过程中，
对于 undo log
对于 update 或者 delete 操作，每一行都保存了一个事务 Id，修改事务 Id 为当前 Session 的事务 id，
生成数据行事务之前的版本，将当前行的回滚指针指向事务之前的版本。
对于 insert 操作，将当前行的回滚指针指为空，因为 insert 没有事务操作之前的版本。
对于 redo log
随着 update\delete\insert 操作的执行，重做日志 Redo Log 不断地写入重做日志缓存（redo_log_buffer）,
对于 Redo Log Buffer 的落盘（写入 Redo Log File），有三种策略：
(1)，事务 commit 的时候，
(2)，redo_log_buffer（默认 8MB）使用超过 50% 的时候，
(3)，发生 checkpoint 的时候
也就是说，Redo Log Buffe 的落盘并不一定是事务提交的时候才写入的，对于大事务，redo log 是有可能逐步落盘的（2,3 两点的影响）
2，事务的提交 Commit
Redo Log Buffer 的写盘，由变量 innodb_flush_log_at_trx_commit 决定，有三种模式分别是 0,1,2
如果设置为 0，事物提交不触发 Redo Log Buffer 写盘，每 N 秒将 Redo Log Buffer 的记录写入 Redo Log 文件，并且将 Redo Log 文件刷入硬件存储 1 次，N 由 innodb_flush_log_at_timeout 控制。
如果设置为 1，事务提交时同步刷新 Redo Log Buffe 到 Redo Log 文件，并且将 Redo Log 文件刷新到磁盘。
如果设置为 2，事务提交时同步刷新 Redo Log Buffe 到 Redo Log 文件，. 但是 Redo Log 的 flush(刷到磁盘)操作并不会同时进行。Redo Log 的写盘由操作系统和 innodb_flush_log_at_timeout 控制。
需要注意的是，innodb_flush_log_at_trx_commit= 1 的情况下，尽管事务提交可以保证 redo log 同步写盘，
但是 Redo Log Buffer 的写盘并不一定只有在事务提交的时候才写入的，有可能是随着时候的执行（如果事务很大）逐步写盘的。
3，事务提之后
因为 redo log 的存在（写盘之后），事务的一致性和持久性得到了保证，对于内存中的脏数据，通过 checkpoint 或者内存机制刷入磁盘，在数据写入磁盘之后，redo log 空间即可释放
对于 undo log，当没有活动 Session 访问的时候，由 purge 线程异步清理 undo log 占用的空间
