前言
MySQL 日志蕴含了谬误日志、查问日志、慢查问日志、事务日志、二进制日志等，如果存储引擎应用的是 InnoDB，二进制日志 (binlog) 和事务日志(包含 redo log 和 undo log) 是必定绕不过来的，本篇接下来具体为大家介绍这三种日志。
redo log
为什么要有 redo log？
咱们都分明，事务的四大个性其中有一个是持久性，简略的说就是只有事务提交胜利，对数据库做的批改就会被永恒保留下来，不会因为任何起因再回到原来的状态。
MySQL 是怎么样保障持久性的呢？最简略的做法是在每次事务提交的时候，将该事务波及批改的数据页全副刷新回磁盘中，可是这么做存在重大的性能问题：
- 单个事务可能波及批改多个数据页，并且数据页在物理上并不间断，应用随机 IO 写入性能太差。
- 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 的区别
次要有以下三方面：
- binlog 是 MySQL 的 Server 层实现的，所有的引擎都是能够的。redo log 是 InnoDB 的日志。如果不应用 InnoDB 引擎，是没有 redo log 的。
- binlog 是逻辑日志，记录的是对哪一个表的哪一行做了什么批改；redo log 是物理日志，记录的是对哪个数据页中的哪个记录做了什么批改，能够了解为对磁盘上的哪个数据做了批改。
- 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 多平台公布