| 逻辑架构图 |
MySQL数据库的设计主要分为4层，它的设计理念完全可以用编程的思维去思考（UBD），我们可以把MySQL分为4层：
第一层：连接层
包括：连接池组件、管理服务和工具组件，最上面是一些客户端和连接服务，包含本地sock通信和大多数基于客户端/服务端工具实现的TCP/IP的通信。主要完成一些类似于连接处理，授权认证，及相关的安全方案。在该层上引入了线程连接池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
第二层：服务层
包括：SQL接口组件、查询分析器组件、优化器组件、缓冲组件，第二层主要完成大多数的核心服务功能，如SQL接口组件，并完成缓存查询，sql的分析和优化及部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如过程、函数等。在该层，服务器会解析查询并创建相应的内部解析书，并对其完成相应的优化如确定查询表的顺序，是否利用索引等，最后生成相应的执行操作。如果是select语句，服务器还会查询内部的缓存，如果缓存足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能
第三层：引擎层
存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API与存储引擎进行通信。不同的存储引擎具有不同的功能，这样我们可以根据自己的实际需要进行选取。MySQL的存储引擎是插件式的存储引擎将查询处理和其它的系统任务以及数据的存储提取相分离，这种架构可根据业务的需求和实际需要选择合适的存储引擎
第四层：存储层
数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的交互
| select 执行过程 |
第一步：发送sql语句给服务端， 通过服务器的权限检查（连接层功能）
第二步：查询缓存
服务器通过权限检查之后(用户名和密码等），查询缓存，如果缓存时打开的，服务器首先检查查询缓存中的数据
- 命中时，MySQL会立即返回结果，省去解析、优化和执行等阶段。否则，进入下一阶段
- MySQL保存结果于缓存中，把select语句本身做hash计算，计算的结果作为key，查询结果作为value
- 查询语句的大小写会影响缓存的存储和命中，故需保持查询语句的大小写一致性
第三步：解析器
mysql解析器使用mysql语法规则验证和解析查询,通过关键字（select，insert等）将SQL语句进行解析，生成对应的“解析树”，此时的树是没有优化的,即检查你编写的sql语句是否有错误
第四步：预处理器
预处理器根据mysql规则进一步检查解析树是否合法，即对解析书进行预处理（有计算的地方得到计算结果，变量的赋值，函数的执行）
第五步：查询优化器
当语法树被认为是合法的了，优化器便将其转化成执行计划，即将sql语句进一步优化，第一步做什么，第二步做什么，比如你的执行顺序是A,B,C但是经过查询优化器分析认为B,A,C执行顺序是最优的
第六步：查询执行引擎
通过调用存储引擎实现的接口来完成引擎的调用，进而完成结果的查询，这些接口被称为handler API
第七步：返回结果
查询执行的最后一个阶段就是将结果返回给客户端。即使查询不到数据，MySQL仍然会返回这个查询的相关信息，比如该查询影响到的行数以及执行时间等等
相关介绍参见美文：https://blog.csdn.net/fuzhongmin05/article/details/70904190，此篇文章介绍了更多的知识点，很值得一读
| 缓存注意事项 |
1.何种语句不会被缓存
- 查询语句中有一些不确定数据时，不会缓存，如now()，current_time()等
- 若查询中包含用户自定义函数，存储函数，用户变量，临时表，mysql库中系统表，或者任何包含权限的表，一般都不会缓存，如包含CURRENT_USER或者CONNECION_ID()的查询语句会因为不同的用户而返回不同的结果，将这样的查询结果缓存起来没有任何的意义
2.缓存会带来额外开销
- 读查询在开始之前必须先检查是否命中缓存
- 若某个读查询可以被缓存且未被缓存，那么当完成执行后，MySQL会将其结果存入查询缓存。
- 对写操作也有影响，因为当写入数据时，MySQL必须将对应表的所有缓存都设置失效，这在缓存内存较大时将导致很大的系统消耗
- 故查询缓存并非必需，其效率取决于全部查询中开销较大的查询是否能被缓存命中