MySQL各模块工作配合

MySQL各模块工作配合

在了解了 MySQL 的各个模块之后，我们再看看 MySQL 各个模块间是如何相互协同工作的 。接下来，我们通过启动 MySQL，客户端连接，请求 query，得到返回结果，最后退出，这样
一整个过程来进行分析。

当我们执行启动 MySQL 命令之后， MySQL 的初始化模块就从系统配置文件中读取系统参数和命令行参数，并按照参数来初始化整个系统，如申请并分配 buffer，初始化全局变量，
以及各种结构等。同时各个存储引擎也被启动，并进行各自的初始化工作。当整个系统初始化结束后，由连接管理模块接手。连接管理模块会启动处理客户端连接请求的监听程序， 包
括 tcp/ip 的网络监听，还有 unix 的 socket。这时候，MySQL Server 就基本启动完成，准备好接受客户端请求了。

当连接管理模块监听到客户端的连接请求（借助网络交互模块的相关功能），双方通过Client & Server 交互协议模块所定义的协议 “寒暄”几句之后，连接管理模块就会将连接
请求转发给线程管理模块，去请求一个连接线程。

 

线程管理模块马上又会将控制交给连接线程模块，告诉连接线程模块：现在我这边有连接请求过来了，需要建立连接，你赶快处理一下。连接线程模块在接到连接请求后，首先会检查当前连接线程池中是否有被 cache 的空闲连接线程，如果有，就取出一个和客户端请求连接上，如果没有空闲的连接线程，则建立一个新的连接线程与客户端请求连接。当然， 连接线程模块并不是在收到连接请求后马上就会取出一个连接线程连和客户端连接，而是首先通过调用用户模块进行授权检查，只有客户端请求通过了授权检查后，他才会将客户端请求和负责请求的连接线程连上。

在 MySQL 中，将客户端请求分为了两种类型：一种是 query，需要调用 Parser 也就是Query 解析和转发模块的解析才能够执行的请求；一种是 command，不需要调用 Parser 就可
以直接执行的请求。如果我们的初始化配置中打开了 Full Query Logging 的功能，那么Query 解析与转发模块会调用日志记录模块将请求计入日志，不管是一个 Query 类型的请求还是一个 command 类型的请求，都会被记录进入日志，所以出于性能考虑，一般很少打开 FullQuery Logging 的功能。

当客户端请求和连接线程“互换暗号（互通协议） ”接上头之后，连接线程就开始处理客户端请求发送过来的各种命令（或者 query），接受相关请求。它将收到的 query 语句转
给 Query 解析和转发模块， Query 解析器先对 Query 进行基本的语义和语法解析，然后根据命令类型的不同，有些会直接处理，有些会分发给其他模块来处理。如果是一个 Query 类型的请求，会将控制权交给 Query 解析器。 Query 解析器首先分析看是不是一个 select 类型的 query，如果是，则调用查询缓存模块，让它检查该 query 在query cache 中是否已经存在。如果有，则直接将 cache 中的数据返回给连接线程模块，然后通过与客户端的连接的线程将数据传输给客户端。如果不是一个可以被 cache 的 query类型，或者 cache 中没有该 query 的数据，那么 query 将被继续传回 query 解析器，让 query解析器进行相应处理，再通过 query 分发器分发给相关处理模块。

如果解析器解析结果是一条未被 cache 的 select 语句，则将控制权交给 Optimizer，也就是 Query 优化器模块，如果是 DML 或者是 DDL 语句，则会交给表变更管理模块，如果是一些更新统计信息、检测、修复和整理类的 query 则会交给表维护模块去处理，复制相关的query 则转交给复制模块去进行相应的处理，请求状态的 query 则转交给了状态收集报告模块。实际上表变更管理模块根据所对应的处理请求的不同，是分别由 insert 处理器、 delete处理器、update 处理器、create 处理器，以及 alter 处理器这些小模块来负责不同的 DML和 DDL 的。在各个模块收到 Query 解析与分发模块分发过来的请求后，首先会通过访问控制模块检查连接用户是否有访问目标表以及目标字段的权限，如果有，就会调用表管理模块请求相应的表，并获取对应的锁。表管理模块首先会查看该表是否已经存在于 table cache 中，如果已经打开则直接进行锁相关的处理，如果没有在 cache 中，则需要再打开表文件获取锁， 然后将打开的表交给表变更管理模块。

当表变更管理模块“获取”打开的表之后，就会根据该表的相关 meta 信息，判断表的存储引擎类型和其他相关信息。根据表的存储引擎类型，提交请求给存储引擎接口模块， 调用对应的存储引擎实现模块，进行相应处理。不过，对于表变更管理模块来说，可见的仅是存储引擎接口模块所提供的一系列 “标准”接口，底层存储引擎实现模块的具体实现，对于表变更管理模块来说是透明的。他只需要调用对应的接口，并指明表类型，接口模块会根据表类型调用正确的存储引擎来进行相应的处理。

当一条 query 或者一个 command 处理完成（成功或者失败）之后，控制权都会交还给连接线程模块。如果处理成功，则将处理结果（可能是一个 Result set，也可能是成功或者失败的标识）通过连接线程反馈给客户端。如果处理过程中发生错误，也会将相应的错误信息发送给客户端，然后连接线程模块会进行相应的清理工作，并继续等待后面的请求，重复上面提到的过程，或者完成客户端断开连接的请求。

如果在上面的过程中，相关模块使数据库中的数据发生了变化，而且 MySQL 打开了 binlog 功能，则对应的处理模块还会调用日志处理模块将相应的变更语句以更新事件的形式记
录到相关参数指定的二进制日志文件中。在上面各个模块的处理过程中，各自的核心运算处理功能部分都会高度依赖整个 MySQL的核心 API 模块，比如内存管理，文件 I/O，数字和字符串处理等等。

 

 

了解到整个处理过程之后，我们可以将以上各个模块画成如图 的关系图：

UNDO