一张简洁的架构图可以很好地帮助你理解MySQL的各个部分如何协同工作。下图展示了MySQL的逻辑架构。

最上方是并非MySQL独有的服务，它们是基于网络的客户端服务器工具，负责鉴权，连接，安全等功能。

第二层是使事情变复杂的一层。很多MySQL的核心功能都在这里，包括查询解析，分析，优化，缓存，以及所有内建函数（比如日期，时间，数学，加密）。跨引擎的功能也在这里：存储过程，触发器，视图等。

第三层包含存储引擎。它们负责处理MySQL中存储的所有数据的保存和查询。就像很多文件系统一样，各种引擎有长处也有短处。服务器通过存储引擎API访问它们，每种存储引擎的API并不相同，但是对于查询层而言，它们是透明的。API负责底层的功能，比如“开启事务”，“查询主键为XX的行”等。存储引擎并不会解析SQL，也不会互相通信，它们只负责管理自己的数据。

连接管理器和安全

每个客户端连接在服务进程中都占有一个单独的线程。查询语句在该线程中运行，这个线程又对应一个CPU或者CPU的一个核心。服务端会缓存线程，这样就不用每次产生一个连接时，重新创建线程。

在MySQL 5.5之后支持通过API自定义线程池，这样少量的线程就可以服务很多客户端。

当客户端连接到MySQL服务器时，服务器需要进行鉴权。鉴权通过用户名，客户端地址和密码完成。也可以通过SSL连接和X.509证书进行。客户端成功连接后，服务器判断客户端队特定的查询是否具有权限。

优化和运行

MySQL在该阶段解析查询语句，生成内部结构（解析树），然后会应用一些优化。具体可能包括重写查询，决定读表顺序，决定索引的使用等等。你可以在查询的时候向优化器输入特定的参数，影响它的决策。你也可以要求服务器解释每个优化的情况。这样你可以知道服务器在每一步的决策，帮助你优化你的查询语句。我们在后续讨论优化器。

优化器通常不会考虑表究竟使用了哪种存储引擎，但是存储引擎确实会影响服务器优化的过程。优化器会询问存储引擎关于一些具体操作的性能，这些可以是对查询结果的统计结果。比如，某些存储引擎支持建立索引，以加快某些查询。我们将在后续讨论索引和表结构优化。

尽管如此，在真正开始查询之前，服务器会询问查询缓存，查询缓存中只能存储SELECT语句，以及它们的查询结果。如果正在进行的查询和之前某个查询完全一致，那么就完全不需要解析、优化或者运行查询，只需要把缓存的结果返回即可。我们在后续讨论这些。