Mysql的体系结构封装着SQL接口、查询解析器、查询优化器和查询执行引擎、缓存/缓冲机制以及一个插件式存储引擎。
Connectors:
是一些用来与客户端应用程序建立连接的数据库接口。
connection pool:连接池
该层负责处理与用户访问有关的各种用户登录、线程处理、内存和进程缓存需求。
SQL Interface : SQL接口
SQL接口提供了从用户接收命令并把结果返回给用户的机制。
MySQL服务器从网络接收连接请求并为每个连接创建一个线程。创建出一个线程之后，MySQL服务器将开始解析SQL命令并把解析出来的各个部分保存到一个内部数据结构里去。
Parser: 解析器
当收到客户端发出的查询并为之创建一个新线程之后，SQL语句将被传递到解析器接受语法验证（或因错误而被拒绝）。
MySQL的解析器读入SQL语句并把该表达式与在源代码里定义的规则进行比较。
在解析器标识该正则表达式并把查询语句分解成一系列基本元素后，它将把适当的命令类型分配给相应的线程结构并把控制权返回给命令处理器。解析器生成的查询结构将被传递到查询处理器，从那开始的后续工作将由查询优化器负责。
查询解析器只检查SQL语句的语法正确定，它不检查有关的表或属性（字段）是否存在，也不检查语义错误（比如没有写出必要的GROUP BY子句）。这些事情由优化器检查。
Optimizer: 查询优化器
优化器使用了一种“选取-投影-联结”策略来处理查询，即先根据又换的限制条件进行选取（SELECT操作）以减少将要处理的元组的个数，再进行投影以减少被选取元组里的属性（字段）的个数，最后根据联结条件生成最终的查询结果。
优化器规则：
@ 通过计算where子句里的表达式来横向排除多余的数据。
@ 只保留在属性（字段）清单里列出的，以及在最后执行联结子句时还需要用到的属性（字段），其他数据全部排除。
@ 根据联结条件生成最终的查询结果
优化器里的第一步： 是检查有关表是否存在以及用户是否有访问权限；如果发现错误，返回一条相应的出错信息并把控制权交还给线程管理器。一旦找到了正确的表，就打开并应用适当的并发控制锁。
优化器里的第二步：在所有的维护和初始化任务全部完成后，优化器将使用内部查询结构对查询命令中的where条件进行处理（选取操作），其结果作为临时表返回供后续步骤做进一步处理。
优化器里的第三步：执行投影操作。 投影操作的执行的中间结果仍保存在临时表里，且只保存那些由SELECT语句中的列规范所执行的属性。、
优化器里的第四步： 检查LEX结构里有没有用联结类给出的JOIN条件；如果有，调用join::optimize()方法。
查询的执行：
查询的具体执行是由一组库方法实现的，每种方法负责完成一种特定的查询操作。
查询缓存：
查询缓存不仅可以缓存查询结构，还可以缓存查询结果本身.
如果某个查询的结果就在缓存里，系统就可以直接取出那些数据返回给客户端而跳过整个查询优化和执行阶段，
Cache和Buffer：缓存和缓冲区
缓冲区和缓冲区子系统负责保证使用频率最高的数据或结构能够以最有效率的方式被访问。
缓存机制包含一些小缓存：
@表缓存
@记录缓存
@键缓存
@权限缓存
@主机名缓存
@其他缓存机制
Engine ：存储引擎
插件式存储引擎的核心是文件访问层的一个抽象接口，任何人都可以利用这个API接口去建立新的文件访问机制。
插件式存储引擎最让人感兴趣的地方是允许你在一个给定的数据库里为每个表指定一个不同的存储引擎，你甚至可以在创建一个表之后改变它的存储引擎。
新炬网络公众号