事务的实现
ACID
A 原子性 一个事务内的操作是一个原子,要么全成功,要么全失败
C 一致性 事务将数据库从一个状态变为另一个状态,事务的前后数据完整性保持一致
I 隔离性 多个事务对其他事务互相隔离
D 持久性 数据不会丢失
事务的实现
Redolog
AD通过redolog实现 C通过undolog实现
redo log包括两部分：一是内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该部分日志是持久的。
在概念上，innodb通过force log at commit机制实现事务的持久性，即在事务提交的时候，必须先将该事务的所有事务日志写入到磁盘上的redo log file和undo log file中进行持久化。
innodb_flush_log_at_trx_commit控制是否刷盘
数据存储是按照页实现的,并且每个logblock存的是数据变化,不是逻辑概念
UndoLog
通过undolog实现了日志的回滚和MVCC
当事务提交的时候，innodb不会立即删除undo log，因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即undo log不能删除。
但是在事务提交的时候，会将该事务对应的undo log放入到删除列表中，未来通过purge来删除。并且提交事务时，还会判断undo log分配的页是否可以重用，如果可以重用，则会分配给后面来的事务，避免为每个独立的事务分配独立的undo log页而浪费存储空间和性能。
通过undo log记录delete和update操作的结果发现：(insert操作无需分析，就是插入行而已)
数据的DELETE操作
delete操作实际上不会直接删除，而是将delete对象打上delete flag，标记为删除，最终的删除操作是purge线程完成的。
update分为两种情况：update的列是否是主键列。
如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
如果是主键列，update分两部执行：先删除该行，再插入一行目标行。
由于其他事务回滚时按照当前的事务记录,如果当前事务删除了UNDOLOG,无法回滚到当前事务提交的版本
