MySQL的WAL机制

MySQL的WAL机制

WAL全称为Write-Ahead Logging，预写日志系统。其主要是指MySQL在执行写操作的时候并不是立刻更新到磁盘上，而是先记录在日志中，之后在合适的时间更新到磁盘中。日志主要分为undo log、redo log、binlog。
当内存数据页跟磁盘数据页内容不一致的时候，我们成这个内存页为“脏页”。内存数据写入磁盘后，内存和磁盘上的数据页内容就一致了，称为“干净页”。
MySQL真正使用WAL的原因是：磁盘的写操作是随机IO，比较耗性能，所以如果把每一次的更新操作都先写入log中，那么就成了顺序写操作，实际更新操作由后台线程再根据log异步写入。这样对于client端，延迟就降低了。并且，由于顺序写入大概率是在一个磁盘块内，这样产生的IO次数也大大降低。所以WAL的核心在于将随机写转变为了顺序写，降低了客户端的延迟，提升了吞吐量。

Undo log（逻辑性日志）

undo log撤销，回滚。当事务回滚或者数据库崩溃的时候，可以利用undo log撤销未提交的事务对数据库产生的影响。
undo log产生和销毁：在事务开始前产生；事务在提交时，并不会立刻删除undo log，innodb会将该事物对应的undo log放入到删除列表中，后面会通过后台线程purge thread进行回收。undo log属于逻辑日志，记录一个变化过程。例如执行一个delete语句，undo log会记录一个insert。
undo log 存储：undo log采用段的方式进行管理和记录。在innodb数据文件中会包含一种rollback segment 回滚段，内部包含1024个undo log段。
undo log 的作用

1. 实现事务的原子性
2. 实现多版本并发控制（MVCC）:事务未提交之前，undo log 保存了未提交的之前的版本数据，undo log 中的数据可作为数据旧版本快照供其他并发事务进行快照读，相当于做了 一个备份。
   

Redo log

redo log 保证了事务的原子性和持久性，是InnoDB引擎特有的，记录着事务里对数据的修改。一条SQL修改，很产生一组redo log信息（包括很多条），这一组才是写入redo log 的最小单元。当数据写入到磁盘之后redo log的信息即可释放。
使用redo log的好处

1. 保证了数据的持久性。
2. redo log只记录了对数据的修改，数据比一页数据小很多，大大减少了IO频率。
3. redo log的写入是顺序写入，而修改磁盘采用的是随机写入。

Redo log工作原理
redo log是为了实现事务的持久性而出现的产物。防止在发生故障的时间点，尚有脏页未写入表的IBD文件中，在重启MySQL的时候，根据redo log进行重做，从而达到事务的未入磁盘数据进行持久化这一特性。如果直接持久化到磁盘上，每次提交事务都将持久化到磁盘，这将增大IO频率，降低效率。持久化到redo log 中和磁盘上虽然都是IO操作，但是持久化到redo log是连续写入，而在磁盘是随机的，因此采用redo log 效率较高。

Redo Log写入机制
Redo log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。内部有两个指针。
write pos记录当前位置，一边写一边后移，写到最后一个文件末尾后就回到0号文件开头。
checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos和checkpoint中间空着的部分可以用来记录新操作。如果两者重合，证明已经写满，不能执行新的更新操作，需要先擦除一些记录。