MySql 日志 简单总结，很简单的那种

参考：

1. https://www.cnblogs.com/wy123/p/8365234.html
2. https://www.cnblogs.com/wy123/p/8353245.html
3. https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html

undo log

作用：

1. 事务执行失败时回滚
2. 崩溃时，对未提交的事务做回滚
3. 用于MVCC，InnoDB的MVCC，其实是使用Undo log来实现的

如何做：

• 每次sql开始前(不一定是事务提交，事务中持续写)，写sql语句的反向sql到undo 日志，日志是逻辑日志
• 插入 需要记录插入的主键；更新需要记录 更新前的值，更新前的索引等
• 使用WAL 比数据提前写入DB
• 理论上 等事务提交，并且 再无事务引用当前版本的记录后，undo日志就没有用了，会等purge线程回收，涉及purge流程

redo log

作用

1. 崩溃时，对已提交未落盘的数据 重做

如何做

• 每次sql执行之后(不一定是事务提交，事务中持续写)，DB数据没有实际落盘，但是会记录redo日志落盘
• redo 日志里记录了修改的记录内容，操作的磁盘的页物理结构，日志属于物理日志

LSN 和 CheckPoint

作用

为了崩溃恢复，redo log 如何和DB落盘的数据匹配上呢，这里需要用到一个序列号，就是LSN了，如何redo 日志的最新LSN 比落盘的DBLSN 更大更新，则说明落盘的数据丢数据了，需要重做redo log来恢复数据

在这期间，因为积累越来越多的LSN，会导致恢复缓慢，所以引入CheckPoint，InnoDB 会在特定时期触发CheckPoint，CheckPoint会把DB 脏页刷盘，将redo log和LSN 和落盘数据的对齐。进而，可以认为，每一个CheckPoint代表之前的数据都是完整无缺的，数据恢复只需要从当前找到最近的CheckPoint的恢复即可。

binlog

作用

1. 二进制日志，在Mysql 服务端产生，用于数据同步。
2. 用于DB 恢复数据
3. 逻辑日志

如何做

• 既有执行的数据，又有回滚需要的数据
• 事务提交的时候统一写入

redo log和binlog 的区别

二者都有数据恢复的功能，但是有以下区别

1. redo log是InnoDB 存储引擎层做的，不通用，binlog是服务层做的，通用
2. redo log是物理日志，包含磁盘操作信息，binlog是逻辑日志，只包含数据操作的日志
3. 也就是说，redo log应当比binlog 多了操作磁盘结构的日志，但同时少了 反向sql的日志，因为这样的日志结构差异，redo log是单机宕机的数据恢复，binlog 是主从复制 并且可以数据恢复到某一个时间点