MySQL是怎么保证持久性的（redo log日志相关）

Mysql中事务的很多实现，都是因为有日志的支撑，比如binlog、undo log、redo log等

MySQL是怎么保证持久性的

持久性是指，事务一旦提交，它对数据库的改变就应该是永久性的，接下来的其他操作或故障不能对其有影响。InnoDB 中主要是通过 redo log 来保证事务的持久性。

redo log（重做日志），记录的是事务提交时数据页的物理修改，作用是为了保障在进行脏页刷新时而出现错误所造成的持久性的问题！

redo log 是 InnoDB 独有的，记录的是某个数据页做了什么修改，每执行一个事务就会产生相应的 redo log。当事务提交时，只需将 redo log 持久化到磁盘即可，可以暂时不考虑将 Buffer Pool 里的脏页写回，而是在合适的时机交给后台线程去做。系统故障崩溃时，MySQL 也可以在重启之后利用 redo log 里的内容恢复数据。

其中还用到了 WAL 技术。

WAL（Write Ahead Logging-先写日志）的关键点在于 MySQL 的写操作并不是立刻写到磁盘上，而是先写日志，然后在合适的时间再写到磁盘上。具体来说，当有一条记录需要更新时，InnoDB 引擎会先把物理修改记录写到redo log里【即在commit后会立即将redolog Buffer中redo log的日志信息刷新到磁盘中的redo log file（重做日志文件）中】，这个时候整个记录的更新就算完成了。后续，InnoDB 引擎会在适当的时候，由后台线程将缓存在 Buffer Pool 里的脏页刷新到磁盘里，这个时候往往也是系统空闲的时候，以减少对用户线程的影响。

有了 redo log，当系统崩溃时，即使脏页的数据还没来得及持久化，但 redo log 已经持久化了，MySQL 就可以根据 redo log 里记录的内容，将所有的数据恢复到最新状态，整个过程也就是常说的 crash-safe 能力。

redo log日志文件由两部分构成：

- 重做日志缓冲（redo log buffer） ---存在内存中

- 重做日志文件（redo log file） ---存在磁盘中

下面详细阐述一下该过程:

首先用户开启事务，进行一系列的DML(增、删、改)的操作。会先去看内存结构中的缓冲池(Buffer Pool)中是否有要操作的数据，如果有直接操作。

如果没有要先用后台线程将数据从磁盘中读取出来缓存到缓冲池(Buffer Pool)中，然后DML（更新或删除）操作的就是缓冲池中的数据。

操作完缓冲池中的数据后，会立即记录当前事务中的物理修改信息(数据页物理变化)到内存结构中的重做日志缓冲区Redolog Buffer中，

相关说明：

MySQL的Buffer Pool是一个内存区域，用于缓存数据页，从而提高查询性能。读写过程涉及到数据的从磁盘到内存的读取，以及在内存中的修改和写回磁盘。
操作完缓存池中的数据后，数据发生变更，但磁盘中的数据未变，这种数据叫做"脏页"，后续需要后台线程找个时机刷新到磁盘中，完成数据的持久化

但是需要注意的是，脏页写回磁盘是由一个后台线程进行的，在MySQL服务器空闲或负载较低时，InnoDB会进行脏页刷盘，以减少对用户线程的影响，降低对性能的影响。

当事务commit提交后，不会立即将该操作后的"脏页"直接刷新到磁盘中，而是等待一定的频率统一将脏页刷新到磁盘中去，保证缓冲池中的数据和磁盘中数据的一致性。

有了redo log后，commit后虽然不会直接刷新到磁盘中，但是在内存结构中的Redolog Buffer会记录事务中的物理修改信息(即数据页变化)，在commit后会立即将redolog Buffer中redo log的日志信息刷新到磁盘中的redo log file（重做日志文件）中，持久化的保存在磁盘文件中。