《MySQL实战》

最新推荐文章于 2024-10-02 00:27:17 发布

weixin_34348174

最新推荐文章于 2024-10-02 00:27:17 发布

阅读量94

点赞数

文章标签：数据库

原文链接：https://juejin.im/post/5cdaa356f265da03aa4dcbf9

版权

日志系统

一条查询sql语句执行一般是经过连接器，查询缓存，分析器，优化器，执行器等功能模块，最后到达存储引擎。

那么一条更新sql语句的执行流程呢？

如今的MySQL，假如碰到一些生产环境的事故，数据库数据发生巨大错误，这种后果是不允许接受的，但是我们无法保证不出现问题，那么让数据回到错误发生之前就好了，mysql恰恰可以恢复到任何一个时刻（当然要做一些备份操作），下面我们可以讲一下其中的原理。

我们从一个表的一条更新数据说起

mysql> create table T(ID int primary key, c int);
复制代码

如果将ID=2这一行的值+1

mysql> update T set c=c+1 where ID=2;
复制代码

更新操作走的仍然是查询操作的基本链路，前面我们说过在一个表上有更新的时候，跟这个表相关的查询缓存就是失效，所以我们不建议用查询缓存。

接下来，分析器会通过词法和语法解析知道这是一条更新语句。优化器决定要用使用ID这个索引。然后执行器负责执行这一行的更新。

与查询不同的是，更新操作还涉及两个很重要的日志模块，redo log(重做日志),binlog(归档日志)。

redo log

举个例子，如果有人赊账或者还账操作，掌柜一般有两种做法，主要是针对’忙不忙‘

一种是直接把账本拿出来，查找到那个人进行操作
另一种就是先在一个板子上记下这次账，等打样后再进行记录

同样再mysql中，如果每次的更新操作都需要将操作写进磁盘，然后磁盘在写入时也需要找到对应的数据，然后再更新，整个io成本，查找成本都不可忽视。为了解决这个问题，mysql也进行了类似掌柜的操作。

板子和账本配合的操作再MySQL中就是WAL技术，wait ahead logging，先写日志，再写磁盘。

具体来说，当有一条记录需要更新的时候，innodb引擎需要先将记录写道redo log中，并且更新内存，这个时候其实更新记录就已经完成了。innodb会在恰当的时候将这条记录写道磁盘里，往往是系统比较空闲的时候。

但是如果今天真的“很忙”，redo log满了？那么我们还是需要先将数据先写进binlog，为redo log腾出空间，因为redo log在innodb中是固定大小的。比如下面一组4个文件，每个文件的大小是1gb，那么这块redo log就总共可以记录4gb的操作。redo log是从头开始写，写到末尾就回到开头循环写，如下面这幅图

write pos是当前记录的位置，一边写一边后移，写到3后，就会回到0继续写。

checkpoint是擦除的位置（写到磁盘后需要擦除），擦除之前要将记录更新到数据文件。

如果checkpoint被write pos追上了，就说明需要停一下redo log，先进行binlog。

有了redo log，innodb就可以保证即使数据库发生异常重启，之前的记录都不会丢失，这个能力称为crash-safe。比如掌柜忘了打烊后整理到账本，但是板子上的数据仍然存在，可以随时恢复。

binlog

从MySQL整体来看，就有两块，server层，它主要做mysql功能层面的事情；引擎层，负责存储相关的具体事情。而server层也有自己的binlog日志。

为什么会有两份日志呢？

因为最开始MySQL里并没有InnoDB引擎。MySQL自带的引擎是MyISAM，但是MyISAM没有crash-safe的能力，binlog日志只能用于归档。而InnoDB是另一个公司以插件形式引入MySQL的，既然只依靠binlog是没有crash-safe能力的，所以InnoDB使用另外一套日志系统——也就是redo log来实现crash-safe能力。

这两种日志有以下三点不同。