前言
文本已收录至我的GitHub仓库，欢迎Star：github.com/bin39232820…
种一棵树最好的时间是十年前，其次是现在
我知道很多人不玩qq了,但是怀旧一下,欢迎加入六脉神剑Java菜鸟学习群，群聊号码：549684836 鼓励大家在技术的路上写博客
絮叨
我们继续来探索mysql。上一篇文章
一条Select语句的查询过程
大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。
Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服
务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都
在这一层实现，比如存储过程、触发器、视图等。
而存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、
Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成
为了默认存储引擎。
也就是说，你执行 create table 建表的时候，如果不指定引擎类型，默认使用的就是
InnoDB。不过，你也可以通过指定存储引擎的类型来选择别的引擎
连接器
连接器 很好理解就是你输入账号密码去连接mysql ，比如我们navicat客户端，比如我们JDBC数据库连接池这些，都算是连接
连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist
命令中看到它。文本中这个图是 show processlist 的结果，其中的 Command 列显示
为“Sleep”的这一行，就表示现在系统里面有一个空闲连接
建立连接的过程通常是比较复杂的，在使用中要尽量减少建立连接的动作，也就是尽量使用长连接。所以我们一般用池技术咯
查询缓存
连接建立完成后，你就可以执行 select 语句了。执行逻辑就会来到第二步：查询缓存。
MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句，也就是类似于redis key 就是你的sql value 就算sql的返回值。
但是大多数情况下我会建议你不要使用查询缓存，为什么呢？因为查询缓存往往弊大于利。
举个例子 假设你这个sql是查当前的订单列表查询，每次只要有人插入订单，那么你这个缓存就要被删除，所以说这样的话，对于跟新数据库还要多一步操作，所以是没有必须的，mysql默认是关闭缓存的，并且在mysql 8中是没有缓存这个概念了。
你可以将参数 query_cache_type 设置成
DEMAND，这样对于默认的 SQL 语句都不使用查询缓存
分析器
如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此
需要对 SQL 语句做解析
分析器先会做“词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL
需要识别出里面的字符串分别是什么，代表什么。
优化器
经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。
优化器是在表里面有多个索引的时候，决定使用哪个索引
执行器
MySQL 通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶
段，开始执行语句
对于有索引的表，执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口，之
后循环取“满足条件的下一行”这个接口，这些接口都是引擎中已经定义好的
小问题
如果表 T 中没有字段 k，而你执行了这个语句 select * from T where
k=1, 那肯定是会报“不存在这个列”的错误： “Unknown column ‘k’ in ‘where
clause’”。你觉得这个错误是在我们上面提到的哪个阶段报出来的呢？
应该是分析器。优化器是对sql语句优化出一个最好的方案，如果没有该表，也就不存
在优化一说，所以应该是在分析器里面对sql做了分析之后，发现没有该表就直接抛异常提示
了。
SQL更新语句是如何执行的？
前面我们系统了解了一个查询语句的执行流程，并介绍了执行过程中涉及的处理模块。相信你还
记得，一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块，最后
到达存储引擎
那么，一条更新语句的执行流程又是怎样的呢？
可以确定的说，查询语句的那一套流程，更新语句也是同样会走一遍
你执行语句前要先连接数据库，这是连接器的工作。
在一个表上有更新的时候，跟这个表有关的查询缓存会失效，所以这条语句就会
把表 T 上所有缓存结果都清空。这也就是我们一般不建议使用查询缓存的原因
接下来，分析器会通过词法和语法解析知道这是一条更新语句。优化器决定要使用 ID 这个索
引。然后，执行器负责具体执行，找到这一行，然后更新。
与查询流程不一样的是，更新流程还涉及两个重要的日志模块，它们正是我们今天要讨论的主
角：redo log（重做日志）和 binlog（归档日志）
重要的日志模块：redo log
不知道你还记不记得《孔乙己》这篇文章，酒店掌柜有一个粉板，专门用来记录客人的赊账记
录。如果赊账的人不多，那么他可以把顾客名和账目写在板上。但如果赊账的人多了，粉板总会
有记不下的时候，这个时候掌柜一定还有一个专门记录赊账的账本。
如果有人要赊账或者还账的话，掌柜一般有两种做法
- 一种做法是直接把账本翻出来，把这次赊的账加上去或者扣除掉
- 另一种做法是先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。
在生意红火柜台很忙时，掌柜一定会选择后者，因为前者操作实在是太麻烦了。首先，你得找到
这个人的赊账总额那条记录。你想想，密密麻麻几十页，掌柜要找到那个名字，可能还得带上老
花镜慢慢找，找到之后再拿出算盘计算，最后再将结果写回到账本上。
在 MySQL 里也有这个问题，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到
对应的那条记录，然后再更新，整个过程 IO 成本、查找成本都很高。为了解决这个问题，
MySQL 的设计者就用了类似酒店掌柜粉板的思路来提升更新效率
而粉板和账本配合的整个过程，其实就是 MySQL 里经常说到的 WAL 技术，WAL 的全称是
Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时
候再写账本
具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）
里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操
作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就像打烊以后掌柜做的
事。
与此类似，InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大
小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开
头循环写，如下面这个图所示。
wirte pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。
checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据
文件。
write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果
write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦
掉一些记录，把 checkpoint 推进一下。
有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，
这个能力称为crash-safe。
重要的日志模块：binlog
MySQL 整体来看，其实就有两块：一块是 Server 层，它主要做的是 MySQL
功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。上面我们聊到的粉板 redo
log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为 binlog（归档日志）。
为什么会有两份日志呢？
因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，但是 MyISAM
没有 crash-safe 的能力，binlog 日志只能用于归档。而 InnoDB 是另一个公司以插件形式引入
MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系
统——也就是 redo log 来实现 crash-safe 能力。
redo log 和binlog的区别
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可
以使用 - redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，
记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 - redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指
binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
真正的执行流程
update T set c=c+1 where ID=2;
- 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2
这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内
存，然后再返回。 - 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的
一行数据，再调用引擎接口写入这行新数据。 - 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo
log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务 - 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状
态，更新完成。
可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库
的状态不一致。
简单说，redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态
保持逻辑上的一致。
结尾
文章出自极客时间的Mysql45讲，非常不错哦
日常求赞
好了各位，以上就是这篇文章的全部内容了，能看到这里的人呀，都是真粉。
创作不易，各位的支持和认可，就是我创作的最大动力，我们下篇文章见
六脉神剑 | 文 【原创】如果本篇博客有任何错误，请批评指教，不胜感激 ！
近期评论