MySQL 基础架构

MySQL 基础架构分析

MySQL 基本架构概览

flowchart LR
subgraph z ["Server层"]
a(["连接器"]):::object --> b("分析器"):::object --> c("优化器"):::object -->d("执行器"):::object
a --> e[("查询缓存")]:::engine
b --> e
end
z:::bg
d-->u1[("存储引擎")]:::engine
classDef bg fill:#94c2d1;
%% classDef object fill:#f9f;
classDef engine fill:#bebebe;

简单来说 MySQL 主要分为 Server 层 和 存储引擎层：

Server 层：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binglog 日志模块。
存储引擎：主要负责数据的存储和读取，采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎，其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了。

Server 层基本组件

连接器
- 用户身份认证，校验账户密码。
- 从权限表中查询用户所有的权限，供之后使用。
  权限查询后，所有权限逻辑判断都依赖该权限。即，连接不断开，虽然中途权限被修改，也不会影响当前连接过程。
查询缓存
- 从缓存中查询结果，没有则返回。
- MySQL 8.0 版本后移除。
分析器
- 词法分析，提取 SQL 语句每个词语转换为 token。
- 语法分析，根据 token 确定语法结构，顺便判断语法结构是否正确。
优化器
- 判断尽可能最优的执行方案，比如多个索引时该如何选择索引，多表查询时如何选择关联顺序。
执行器
- 校验用户是否有权限
- 调用引擎接口并返回接口执行结果

连接器

连接器负责跟客户端建立连接、获取权限、维持和管理连接。

但是全部使用长连接后，你可能会发现，有些时候 MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。

怎么解决这个问题呢？你可以考虑以下两种方案。

定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。
如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它。文本中这个图是 show processlist 的结果，其中的 Command 列显示为“Sleep”的这一行，就表示现在系统里面有一个空闲连接。

MySQL 整理.png|600

客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。

分析器

MySQL 没有命中缓存，那么就会进入分析器，分析器主要是用来分析 SQL 语句是来干嘛的，分析器也会分为几步：

第一步，词法分析，一条 SQL 语句有多个字符串组成，首先要提取关键字，比如 select，提出查询的表，提出字段名，提出查询条件等等。做完这些操作后，就会进入第二步。

第二步，语法分析，主要就是判断你输入的 SQL 是否正确，是否符合 MySQL 的语法。

完成这 2 步之后，MySQL 就准备开始执行了，但是如何执行，怎么执行是最好的结果呢？这个时候就需要优化器上场了。

优化器

优化器的作用就是它认为的最优的执行方案去执行（有时候可能也不是最优，这篇文章涉及对这部分知识的深入讲解），比如多个索引的时候该如何选择索引，多表查询的时候如何选择关联顺序等。

可以说，经过了优化器之后可以说这个语句具体该如何执行就已经定下来。

执行器

当选择了执行方案后，MySQL 就准备开始执行了，首先执行前会校验该用户有没有权限，如果没有权限，就会返回错误信息，如果有权限，就会去调用引擎的接口，返回接口执行的结果。

🪴 Obsidian Publish

探索

MySQL 基础架构