MySQL如何保证一致性
数据库通过原子性（A）、隔离性（I）、持久性（D）来保证一致性（C）。其中一致性是目的，原子性、隔离性、持久性是手段。因此数据库必须实现AID三大特性才有可能实现一致性。
MySQL如何保证原子性
利用InnoDB的undo log undo log（回滚日志）记录需要回滚的日志信息，是实现原子性的关键，当事务回滚时能够撤销所有已经成功执行的sql语句
例如
- delete一条数据的时候，就会记录这条数据的曾经的信息，回滚的时候，insert这条旧数据
- update一条数据的时候，就会记录之前的旧值，回滚的时候，根据旧值执行update操作
- insert一条数据的时候，就会这条记录的主键，回滚的时候，根据主键执行delete操作
undo log记录了这些回滚需要的信息，当事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。
MySQL如何保证持久性
利用Innodb的redo log
Mysql修改数据的大概流程是先把磁盘上的数据加载到内存中，在内存中对数据进行修改，再刷回磁盘上。如果此时突然宕机，内存中的数据就会丢失。 如何解决该问题
最直观的想法，事务提交前直接把数据写入磁盘
这么做有什么问题
- 浪费资源，只修改一个页面里的一个字节，就要将整个页面刷入磁盘（一个页面16kb，每次改动都需要将16kb的内容刷入磁盘）
- 速度慢，每个事务里可能涉及到多个数据页的修改，而这些数据可能是不相邻的，属于随机操作IO
于是，决定采用redo log解决上面的问题。当做数据修改的时候，不仅在内存中操作，还会在redo log中记录这次操作。当事务提交的时候，会将redo log日志进行刷盘(redo log一部分在内存中，一部分在磁盘上)。当数据库宕机重启的时候，会将redo log中的内容恢复到数据库中，再根据undo log和binlog内容决定回滚数据还是提交数据。
采用redo log的优点
redo log进行刷盘的效率要远高于数据页刷盘，具体表现如下
- redo log体积小，只记录了哪一页修改的内容，因此体积小，刷盘快
- redo log是一直往末尾进行追加，属于顺序IO。效率显然比随机IO来的快
MySQL 如何保证隔离性
利用锁和MVCC机制
MVCC(Multi Version Concurrency Control)即多版本并发控制，一个行记录数据有多个版本对快照数据，这些快照数据在undo log中。 如果一个事务读取的行正在做DELELE或者UPDATE操作，读取操作不会等行上的锁释放，而是读取该行的快照版本。
由于MVCC机制在可重复读(Repeateable Read)和读已提交(Read Commited)的MVCC表现形式不同在后续文章中将进行详细描述。
在事务隔离级别为读已提交(Read Commited)时，一个事务能够读到另一个事务已经提交的数据，是不满足隔离性的。但是当事务隔离级别为可重复读(Repeateable Read)中，是满足隔离性的。
