MySQL----日志-优快云博客

三个日志种类

undo log(回滚日志): 实现事务中的原子性，每执行一条数据修改语句，就记录一条相反的语句，当rollback时读取undo log中的记录恢复数据。

redo log(重做日志): 实现事务持久性，记录修改后的数据，用于故障后数据丢失的恢复

bin log(归档日志): 用于数据备份与主从复制

undo log(回滚日志) 原子性

实现事务回滚，保障事务的原子性: 当一条数据修改语句执行后会在undo log中记录一条相反的语句，当事务需要回滚时就读取undo log中的命令进行数据恢复，且事务提交或回滚后undo log并不会立马删除，还可用于MVCC。

实现MVCC(多版本并发控制)的关键因素: MVCC通过ReadView + undo log共同实现，通过记录一系列事务id以及隐藏字段roll_pointer构成的undo log版本链，控制事务可见的数据版本。

redo log(重做日志) 持久性

redo log buffer 重做日志缓冲(内存) redo log file重做日志文件(磁盘)

当客户端有多条数据更新语句需要执行，首先看缓冲池(buffer pool)中有无对应的数据，若没有则通过后台线程从磁盘中读取原数据到缓冲池，接下来执行数据更新语句更新缓冲池中的数据，此时磁盘中的数据还没有与缓冲池中的数据做同步，磁盘中对应的数据页就成为了脏页，后续在一定时机将脏页中的数据刷新到磁盘中，但在此间隙中若因为各种原因导致数据罗盘失败，那么此时就出现了事务提交成功但数据丢失的情况。

解决方案: 增加redo log,当要进行数据更新时，缓冲池中的数据变更后，首先会将变更的数据记录在redo log buffer(重做日志缓冲中),在事务提交时会直接将redo log buffer(内存)中的数据直接持久化到redo log file重做日志文件(磁盘)，若一段时间后脏页刷新时出现错误直接根据redo log file中的内容恢复数据，且如果事务提交就立即刷新磁盘中脏页的数据会涉及到大量随机磁盘IO性能较低，而如果先写日志再追加则是顺序磁盘IO，性能更高。

“redo log（重做日志）: 通过记录事务对数据页的物理修改，确保事务的持久性（Durability）。采用顺序写入和WAL机制提升性能，并在崩溃恢复时重放日志以修复未刷盘的数据。”

若没有redo log为了避免长时间不落盘导致大量数据丢失就只能在较短的时间内将buffer pool中的数据落盘，此时是大量随机磁盘IO性能低下；如果有redo log就先将数据追加到redo log file中是顺序磁盘IO性能更高，后续再将buffer pool中的数据在合适的时机异步慢慢落盘，将随机磁盘IO的影响降到最低。