从语句执行窥探架构设计

大体来说，MySQL 可以分为 Server 层和存储引擎层两部分：

• Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。
• 存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。

不同的存储引擎共用一个 Server 层，也就是从连接器到执行器的部分。

查询语句的执行

客户端和 MySQL 服务端的交互过程简介：

• 客户端发送一条 SQL 语句给服务端，服务端的连接器先进行账号/密码、权限等环节验证，有异常直接拒绝请求。
• 服务端查询缓存，如果 SQL 语句命中了缓存，则返回缓存中的结果，否则继续处理。
• 服务端对 SQL 语句进行词法解析、语法解析、预处理来检查 SQL 语句的合法性。
• 服务端通过优化器对之前生成的解析树进行优化处理，生成最优的物理执行计划。
• 将生成的物理执行计划调用存储引擎的相关接口，进行数据查询和处理。
• 处理完成后将结果返回客户端。

以下面的简单查询语句为例，我们来讨论下一条 SQL 查询语句在 MySQL 中是如何被执行的：

mysql> select * from T where ID=10；

• 连接器：首先，你会先连接到这个数据库上，这时候接待你的就是连接器。连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它。客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。

• 查询缓存：连接建立完成后，你就可以执行 select 语句了。执行逻辑就会来到第二步：查询缓存。MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。不过大多数情况下我会建议你不要使用查询缓存，为什么呢？因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。

• 分析器：如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此需要对 SQL 语句做解析。分析器先会做“词法分析”,词法分析完后就要做“语法分析”。根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。如果你的语句不对，就会收到“You have an error in your SQL syntax”的错误提醒

• 优化器：经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。比如你执行下面这样的语句，这个语句是执行两个表的 join： mysql> select * from t1 join t2 using(ID) where t1.c=10 and t2.d=20; 既可以先从表 t1 里面取出 c=10 的记录的 ID 值，再根据 ID 值关联到表 t2，再判断 t2 里面 d 的值是否等于 20。也可以先从表 t2 里面取出 d=20 的记录的 ID 值，再根据 ID 值关联到 t1，再判断 t1 里面 c 的值是否等于 10。这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。

• 执行器：MySQL 通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误。如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。

至此，这个整个语句就执行完成了。一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块，最后到达存储引擎。

更新语句的执行

与查询流程不一样的是，更新流程还涉及两个重要的日志模块 Redo Log（重做日志）和 binlog（归档日志）。

update T set c=c+1 where ID=2;

每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程 IO 成本、查找成本都很高。为了解决这个问题，MySQL 的设计者采用 WAL 技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 Redo Log 里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。但是 InnoDB 的 Redo Log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB,总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写。

在进行 Redo Log 写入时，有两个重要参数的 write pos(当前记录的位置)，checkpoint 是当前要擦除的位置：

• write pos 是当前记录的位置，一边写一边后移，写到最后一个文件末尾后就回到 0 号文件开头；
• checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件；

write pos 和 checkpoint 之间还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoin，表示 Redo Log 满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。有了 Redo Log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe(崩溃安全)。注意，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 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如 update T set c=c+1 where ID=2。
• Redo Log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 Binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

接下来执行器和 InnoDB 引擎在执行这个简单的 update 语句时的内部流程:

• 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
• 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
• 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
• 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
• 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。
• redo log 的写入拆成了两个步骤：prepare 和 commit，这就是所谓的两阶段提交。

这里，总共有 3 个阶段：1-prepare 阶段，2-写 binlog，3-commit，不同阶段如果数据库崩溃了会有不同的应对：

• 当在 2 之前崩溃时，重启恢复，后发现没有 commit，回滚。这里因为还未写入到 Binlog，因此使用备份恢复的时候会被忽略。
• 当在 3 之前崩溃，重启恢复：虽没有 commit，但满足 prepare 和 binlog 完整，所以重启后会自动 commit。这里因为已经写入到了 Binlog，如果使用备份恢复的话可以保证数据一致性。

事务隔离

事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在 MySQL 中，事务支持是在引擎层实现的。MySQL 默认的 MyISAM 引擎就不支持事务，这也是 MyISAM 被 InnoDB 取代的重要原因之一。MySQL 中的事务管理概述了数据插入、更新、删除等流程中的引擎相关操作（使用 show variables like '%isolation%'; 查看当前设置的隔离级别），在更新语句执行时，存储引擎会分配事务 ID，开启事务，获取锁，没有获取到锁则等待。

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准，除了串行化”隔离级别下直接用加锁的方式来避免并行访问。在可重复读隔离级别（隔离级别相关介绍参阅《Database-Notes/隔离级别》）下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在读提交隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。读未提交隔离级别下直接返回记录上的最新值，没有视图概念。而实际上每条记录在更新的时候都会同时记录一条回滚操作；记录上的最新值，通过回滚操作，都可以得到前一个状态的值。

假设一个值从 1 被按顺序改成了 2、3、4，在回滚日志里面就会有类似下面的记录。不同时刻启动的事务会有不同的 read-view，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）：