mysql github week2_week2-MySQL日志系统

MySQL日志系统

执行一条查询SQL语句需要依次经过连接器->分析器->优化器->执行器->存储引擎，前四者与查询缓存共同构成Server层。

而相对于查询语句，更新语句流程涉及两个重要的日志模块redo log和 binlog。其中InnoDB有redo log而MyISAM没有。

为什么需要redo log，我们知道数据写入磁盘需要进行I/O操作，假设每一次的更新都需要I/O操作，那么这样成本太高。设计者提出redo log来提高效率，这就MySQL的WAL 技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。

但有一条数据需要更新时，InnoDB引擎会将记录写到redo log上，更新内存，这个更新就算完成了，等到空闲时，再将记录写入磁盘。redo log在逻辑上的结构是一个环形的队列，大小是固定的。当redo log写满时，引擎会暂停去将redo log的记录的写入磁盘腾出空间。

Server 层也有自己的日志，称为 binlog(归档日志)。

两种日志的不同之处在于：

​1、redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以 使用。

​2、redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录 的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。

​3、redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

更新记录操作与两阶段提交

不同于查询操作首先进入查询缓存，更新操作时，关于这个表的查询缓存会失效，清空。基于这个原因，不建议使用查询缓存，并且在新版本的MySQL中查询缓存的功能已经被舍弃。

下面我将画一个图表示更新语句的操作流程。

可以看出，redo log是分两次提交的，两次中间写入binlog。为什么需要两阶段提交呢？其实就是保证redo log与binlog是同步的。你可以将最后三步看作是一个事务，要么都成功，要么都失败。可以设想一下如果没有两阶段提交，会出现什么情况。

假设当前 ID=2 的行，字段 c 的值是 0，再假设执行 update 语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了 crash，会出现什么情况呢？

先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。

先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。

文章是关于丁奇老师MySQL实战45讲的总结。