MySQL日志笔记

MySQL日志主要有三种

redo log

redo log是MySQL的Innodb存储引擎特有的日志，redo log的作用是用来做持久化的，ACID特性的持久性，就是redo log做的，它使得MySQL拥有crash-safe能力，也就是即使数据库发生异常重启，之前提交的记录都不会丢失。

当有一条记录需要更新的时候，他会先把这个更新写到redo log里边，然后再更新内存，这样就算是更新完成了，等到磁盘比较空闲的时候，他再把这个记录同步到磁盘里边。

redo log的大小是固定的，当写到末尾后又回到开头循环写，如果写满了，那么这时候不能再执行新的更新，它会停下来先把数据同步到磁盘，进而腾出空间，然后再执行更新操作，这种情况有时候会导致SQL语句查询慢的问题，因为MySQL有时会停下其他操作，全身心的去把数据同步到磁盘，然后才执行我们的SQL语句

redo log的持久性是怎么做到的

如果写入内存成功，但数据还没真正刷到磁盘，如果此时的数据库挂了，我们可以靠redo log来恢复内存的数据，这就实现了持久性

binlog

redo log是Innodb存储引擎的，而在Server层也有自己的日志，也就是binglog，binlog会记录那些，修改表结构，或者更新表数据的SQL语句，（不包括查询语句），binlog的作用是复制和恢复。

复制：
MySQL主从复制的原理就是基于binlog，主从服务器需要保持数据的一致性，通过binlog来同步数据。

恢复：
如果整个数据库的数据都被删除了，binlog存储着所有的数据变更情况，那么可以通过binlog来对数据进行恢复

如果数据库被删，基于redo log可以恢复吗？

不能 ! ! ! 因为功能的不同，redo log 存储的是物理数据的变更，如果我们内存的数据已经同步到了磁盘，那redo log的数据就无效了。所以redo log不会存储着历史所有数据的变更，文件的内容会被覆盖的。

redo log与binlog的区别

redo log是物理日志，记录的是在哪个数据页上执行了哪些操作，binlog是逻辑日志，记录的是SQL语句

什么是undo log

undo log主要有两个作用：回滚和多版本控制(MVCC)

在数据修改的时候，不仅记录了redo log，还记录undo log，如果因为某些原因导致事务失败或回滚了，可以用undo log进行回滚

undo log主要存储的也是逻辑日志，比如我们要insert一条数据了，那undo log会记录的一条对应的delete日志。我们要update一条记录时，它会记录一条对应相反的update记录。

这也应该容易理解，毕竟回滚嘛，跟需要修改的操作相反就好，这样就能达到回滚的目的。因为支持回滚操作，所以我们就能保证：“一个事务包含多个操作，这些操作要么全部执行，要么全都不执行”。【原子性】

因为undo log存储着修改之前的数据，相当于一个前版本，MVCC实现的是读写不阻塞，读的时候只要返回前一个版本的数据就行了。

参考：MySQL三种日志