从语句执行窥探架构设计

从语句执行窥探架构设计

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

MySQL 架构简图

  • 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是当前要擦除的位置：

Redo 日志中检查点与写入点

  • 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）：

多版本隔离

上一页
下一页

最近更新于0001-01-01