MySQL的log日志文件

MySQL的那些log日志文件

一、binlog日志

binlog其实在日常的运维开发中是听得很多的，因为很多时候数据库数据的更新就是依赖binlog日志的。

比如我们的数据保存在数据库中，现在我们有新的数据写入，或者有数据被更改致使数据库发生变更，而用户检索出来数据是走搜索引擎的，为了用户能搜到最新的数据我们需要把引擎的数据也改掉。

总之就是：数据库变更，搜索引擎也需要变更，于是我们就会监听binlog的变更，如果binlog变更了。那么我们就需要将变更写入到对应的数据源中

什么是binlog？

binlog记录了数据库表结构和表数据变更,比如update/delete/insert/truncate/create。它不会记录select，因为这个没有对表进行变更。

binlog到底是什么样的？binlog我们可以理解位存储着每条变更的SQL语句。

binlog一般用来干什么？

主要的两个作用：复制和恢复数据

。MySQL在公司使用的时候往往都是一主多从结构的，从服务器需要与主服务器的数据保持一致，这就是通过binlog来是实现的，

。数据库的数据被干掉了，我们可以通过binlog来对数据进行恢复。

因为binlog记录了数据库表的变更，所以我们可以用binlog进行复制和恢复数据

二、什么是redo log

我们来看一条sql语句

update user_table set name='java3y' where id = '3';

MySQL执行这条语句，肯定先把id=3这条语句查出来，然后将name字段给改掉。这没问题吧？

实际上MySQL的基本存储结构是页，所以MySQL是先把这条记录所在的页找到，然后把该页加载到内存中，将对应记录进行修改。

现在就可能出现一个问题；如果在内存中把数据改了还没来得及写入磁盘，而此时的数据库挂了怎么办，显然这次修改就丢失了。

如果每个请求都需要将数据立马写入磁盘之后，那速度会很慢，MySQL可能也顶不住，所以MySQL引入了redo log, 内存写完了，然后会写一份redo log, 这份redo log 记载着这次在某个页做了什么修改。

其实写redo log的时候，也会有buffer, 是先写buffer，在真正写入到磁盘中的，至于从buffer什么时候写入磁盘，会有配置供我们配置。

写redo log也是需要写磁盘的，但它的好处就是顺序IO，所以，redo log 的存在为了当我们修改的时候，写完内存了，但数据还没真正写到磁盘的时候，此时数据库挂了，我们可以对数据进行恢复。因为redo log 是顺序IO，所以写入速度很快，并且redo log 记载的是物理变化，文件的体积小，恢复速度很快。

redo log的作用是为了持久化而生的。写完内存，如果数据库挂了，那我们可以通过redo log来恢复内存还没来得及写入磁盘的数据，将redo log加载到内存里面，那内存就能恢复到挂掉之前的数据了

三、什么是undo log

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

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

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

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

【原子性】

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