前言

MySQL 日志蕴含了谬误日志、查问日志、慢查问日志、事务日志、二进制日志等,如果存储引擎应用的是 InnoDB ,二进制日志(binlog)和事务日志(包含redo log和undo log) 是必定绕不过来的,本篇接下来具体为大家介绍这三种日志。

redo log

为什么要有 redo log ?

咱们都分明,事务的四大个性其中有一个是持久性,简略的说就是只有事务提交胜利,对数据库做的批改就会被永恒保留下来,不会因为任何起因再回到原来的状态。

MySQL 是怎么样保障持久性的呢?最简略的做法是在每次事务提交的时候,将该事务波及批改的数据页全副刷新回磁盘中,可是这么做存在重大的性能问题:

  1. 单个事务可能波及批改多个数据页,并且数据页在物理上并不间断,应用随机IO写入性能太差。
  2. Innodb是以页为单位进行磁盘交互的,一个事务有可能只会批改一个数据页中的几个字节,如果这时候将残缺的数据页刷回磁盘的话,很浪费资源。

因而 MySQL 设计出了redo log,当一条记录更新的时候, InnoDB 引擎会先把记录写到 redo log 外面去,同时更新内存,这样就算这条数据更新胜利了,完满地解决了性能问题(文件更小并且是程序IO)。

留神此时数据并没有更新到磁盘上,InnoDB 会在失当的时候把这条记录更新到磁盘下来。这种先写日志而后再将数据刷盘的机制,有个专有名词——WAL(Write-ahead logging)。

redo log 如何刷到磁盘的呢?

redo log蕴含两局部:

  • 内存中的日志缓冲(redo log buffer)
  • 磁盘上的日志文件(redo log file)

每执行一条DML语句,数据库先将记录写入redo log buffer,而后后续某个工夫点再一次性将多个操作记录写到redo log file。MySQL 一共反对三种写入redo log file的机会,通过参数 innodb_flush_log_at_trx_commit 进行配置,如下图所示:

bin log

bin log 是 MySQL 的逻辑日志,由Server层进行记录,用于记录数据库执行的写入性操作(不包含查问)信息,以二进制的模式保留在磁盘中。无论你应用的是任何的存储引擎,mysql数据库都会记录binlog日志。

与redo log日志一样,binlog也有本人的刷盘策略,通过sync_binlog参数管制:

  • 0 :每次提交事务前将binlog写入os cache,由操作系统管制什么时候刷到磁盘
  • 1 :采纳同步写磁盘的形式来写binlog,不应用os cache来写binlog
  • N :当每进行n次事务提交之后,调用一次fsync() os cache中的binlog强制刷到磁盘

bin log 和 redo log 都用于记录的批改之后的值,那么它们之间到底有什么区别呢?

redo log 和 binlog 的区别

次要有以下三方面:

  1. binlog 是 MySQL 的 Server 层实现的,所有的引擎都是能够的。redo log是InnoDB的日志。如果不应用InnoDB引擎,是没有redo log的。
  2. binlog是逻辑日志,记录的是对哪一个表的哪一行做了什么批改;redo log是物理日志,记录的是对哪个数据页中的哪个记录做了什么批改,能够了解为对磁盘上的哪个数据做了批改。
  3. redo log 是有固定大小的,所以它的空间会用完,如果用完的话,肯定要进行一些写入磁盘的操作才能够持续; binlog 是能够追加写入的,也就是 binlog 没有空间的概念,始终写就行了

undo log

数据库事务四大个性中有一个是原子性,原子性指对数据库的一系列操作,要么全副胜利,要么全副失败,不可能呈现局部胜利的状况。实际上,原子性底层就是通过undo log实现的。

undo log次要记录了数据的逻辑变动,比方一条UPDATE语句,对应一条相同UPDATE的undo log,一条INSERT语句,对应一条DELETE的undo log,这样在产生谬误时,就能回滚到事务之前的数据状态。

undo log 同时也是MVCC(多版本并发管制)实现的要害,这部分公众号之前有讲过,不再赘述。

总结

  • redo log是InnoDB存储引擎的一种日志,次要作用是解体复原,刷盘策略参数 innodb_flush_log_at_trx_commit 举荐设置成2。
  • binlog是MySQL Server层的一种日志,次要作用是归档。
  • undo log是InnoDB存储引擎的一种日志,次要作用是回滚。

本文由mdnice多平台公布