第三章 MySQL底层架构

 一 MySQL的基本架构图

 

连接器

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

　　　　– 用户名密码验证

　　　　– 查询权限信息，分配对应的权限

　　　　– 可以使用show processlist查看现在的连接

　　　　– 如果太长时间没有动静，就会自动断开，通过wait_timeout控制，默认8小时

　　▪ 连接可以分为两类：

　　　　– 长连接：推荐使用，但是要周期性的断开长连接

　　　　– 短链接：

 

 

查询缓存

　　▪ 当执行查询语句的时候，会先去查询缓存中查看结果，之前执行过的sql语句及其结果可能以key-value的形式存储在缓存中，如果能找到则直接返回，如果找不到，就继续执行后续的阶段。

　　▪ 但是，不推荐使用查询缓存：

　　　　– 1、查询缓存的失效比较频繁，只要表更新，缓存就会清空

　　　　– 2、缓存对应新更新的数据命中率比较低

 

分析器

　　▪ 词法分析：Mysql需要把输入的字符串进行识别每个部分代表什么意思

　　　　– 把字符串 T 识别成 表名 T

　　　　– 把字符串 ID 识别成 列ID

　　▪ 语法分析：

　　▪ 根据语法规则判断这个sql语句是否满足mysql的语法，如果不符合就会报错“You have an error in your SQL synta”

 

 

优化器

　　▪ 在具体执行SQL语句之前，要先经过优化器的处理

　　　　– 当表中有多个索引的时候，决定用哪个索引

　　　　– 当sql语句需要做多表关联的时候，决定表的连接顺序

　　　　– 等等

　　▪ 不同的执行方式对SQL语句的执行效率影响很大

　　　　– RBO( Rule_Based Potimizer):基于规则的优化:

　　　　RBO所用的判断规则是一组内置的规则，这些规则是硬编码在数据库的编码中的，RBO会根据这些规则去从SQL诸多的路径中来选择一条作为执行计划（比如在RBO里面，有这么一条规则：有索引使用索引。那么所有带有索引的表在任何情况下都会走索引）所以，RBO现在被很多数据库抛弃（oracle默认是CBO，但是仍然保留RBO代码，MySQL只有CBO。RBO最大问题在于硬编码在数据库里面的一系列固定规则，来决定执行计划。并没有考虑目标SQL中所涉及的对象的实际数量，实际数据的分布情况，这样一旦规则不适用于该SQL，那么很可能选出来的执行计划就不是最优执行计划了

　　　　– CBO(Cost_Based Potimizer):基于成本的优化:

　　　　CBO在会从目标诸多的执行路径中选择一个成本最小的执行路径来作为执行计划。这里的成本他实际代表了MySQL根据相关统计信息计算出来目标SQL对应的步骤的IO，CPU等消耗。也就是意味着数据库里的成本实际上就是对于执行目标SQL所需要IO,CPU等资源的一个估计值。而成本值是根据索引，表，行的统计信息计算出来的。(计算过程比较复杂)

 

执行器

　　▪ sql语句的实际执行组件，负责操作引擎，返回结果数据；
　　▪ sql语句在sql层的流程：
　　　　– 用户传入sql
　　　　– 查询缓存（命中缓存可直接返回结果）
　　　　– 解析器（生成sql解析树）
　　　　– 预处理器（可能sql等价改写）
　　　　– 查询优化器（生成sql执行计划）
　　　　– 查询执行引擎
　　　　– 结果返回给用户