MySQL事务的ACID，其中（C）一致性是最终目的。

保证一致性的措施有：
A原子性：靠undo log来保证（异常或执行失败后进行回滚）。
D持久性：靠redo log来保证（保证当MySQL宕机或停电后，可以通过redo log最终将数据保存至磁盘中）。
I隔离性：事务间的读写靠MySQL的锁机制来保证隔离，事务间的写操作靠MVCC机制（快照读、当前读）来保证隔离性。
C一致性：事务的最终目的，即需要数据库层面保证，又需要应用层面进行保证，并且MySQL底层通过两阶段提交事务保证了事务持久化时的一致性。

注：什么是undo log和redo log
undo log 属于逻辑日志，它记录的是SQL执行相关的信息。当事务对数据库进行修改时，InnoDB会生成与之对应的undo log。如果事务执行失败或者调用的rollback，导致事务需要回滚，InnoDB引擎会根据undo log中的记录，将数据回滚到之前的样子。

redo log：持久性是指事务一旦提交，对数据库的操作就是永久性的，接下来的其他操作和异常故障不应该对它有任何影响。
我们都知道MySQL的数据最终是存放在磁盘中的，所以才会有磁盘的容量大小决定数据容量的大小。但是如果对MySQL的操作都是通过读写磁盘来进行的话，那么光是磁盘的I/O就够把效率大大的拉低了。
所以InnoDB为MySQL提供了缓冲池（Buffer Pool）,Buffer Pool中包含了磁盘中部分数据页的映射。
当从数据库读取数据时，会先从Buffer Pool中读取数据，如果Buffer Pool中没有，则从磁盘读取后放入到Buffer Pool中。
当向数据库写入数据时，会先写入到Buffer Pool中，Buffer Pool中更新的数据会定期刷新到磁盘中（此过程称为刷脏）。
虽然Buffer Pool为MySQL的读写提高了效率，但是却也带来了新的问题，那就是如果数据刚更新到Buffer Pool中还没来得及刷新到磁盘中时，MySQL突然宕机了，这就会导致数据丢失，造成事务的持久性无法保证了。
为了解决这个缓存的一致性问题，redo log就出现了。在对Buffer Pool中的数据进行修改的时候通过redo log记录这次操作，当事务提交时会通过fsync接口对redo log进行刷盘。
因为在事务提交时会把redo log是同步在磁盘中的，所以当MySQL出现宕机时，可以从磁盘中读取redo log进行数据的恢复，从而保证了事务的持久性。
redo log 采用的预写的方式记录日志，即先记录日志，再更新Buffer Pool，这样就强行的保证了，数据只要保存在了redo log中就一定会存储到磁盘中了。

这要解释一下，redo log 也是写磁盘，刷脏也是写磁盘，为啥要先记录redo log而不是直接刷脏？
主要原因就是redo log比刷脏快很多。
第一点是，redo log是追加操作日志，是顺序IO；而刷脏是随机IO，因为每次更新的数据不一定是挨着的，也就是随机的。
第二点是，刷脏是以数据页（Page）为单位的（即每次最少从磁盘中读取一页数据到内存，或者最少刷一页数据到磁盘），MySQL默认页大小是16KB，对一个页上的修改，都要整个页都刷到磁盘中；而redo log只包含真正的需要写入磁盘的操作日志。
————————————————
版权声明：本文为CSDN博主「YangYoung_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/YangYoung_/article/details/117195841