如果能在脑海中构建出一幅MySQL各组件之间协同工作的架构图，那么这将有助于你深入理解MySQL服务器
3️⃣ 三层结构
每一层都有其侧重功能，标粗
🔐 L1：连接处理、身份验证、确保安全性……
并不是MySQL独有的，大多数基于网络通信的C/S类型的工具或服务器都有类似的服务
🛠️ L2：查询解析、分析、优化、以及所有的内置函数（例如，日期、时间、数学和加密函数）……
大多数MySQL的核心功能都在这一层，所有跨存储引擎的功能也都在这一层实现：存储过程、触发器、视图等
💽 L3：负责MySQL中数据的存储和提取，有多种存储引擎可以选择
在服务器中，上层传入的查询通过统一的API与存储引擎进行通信。这些API屏蔽了不同存储引擎之间的差异，使得它们对上面的查询层基本上是透明的，它们也不会去解析SQL。不同存储引擎之间也不会相互通信，而只是简单地响应服务器的请求。
另外，对于并发时需要的各种锁，归不同的存储引擎各自实现。
Note
理论上存储引擎层确实不应该做解析SQL的事情，但InnoDB是一个例外，它会解析外键定义，因为MySQL服务端没有实现该功能。
🔐 连接管理与安全性
L1负责的功能很简单，相当于保安的角色。
连接管理
默认情况下，每个客户端连接都会在服务器进程中拥有一个线程，该连接的查询只会在这个单独的线程中执行，该线程驻留在一个内核或者CPU上。
服务器维护了一个缓存区，用于存放已就绪的线程，因此不需要为每个新的连接创建或者销毁线程。
安全性
登录验证：当客户端连接到MySQL服务器时，服务器需要对其进行身份验证。身份验证基于用户名、发起的主机名和密码。如果以跨传输层安全（TLS）的方式连接，还可以使用X.509证书认证。
权限验证：客户端连接成功后，服务器会继续验证该客户端是否具有其发出的每个查询的权限（例如，是否允许客户端对world数据库中的Country表执行SELECT语句）。
🛠️ 优化与执行
L2负责跨存储引擎的功能，就是说这些功能可以适用于不同的存储引擎。
MySQL解析查询以创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。用户可以通过特殊关键字向优化器传递提示，从而影响优化器的决策过程。也可以请求服务器解释优化过程的各个方面，使用户可以知道服务器是如何进行优化决策的，并提供一个参考点，便于用户重构查询和schema、修改相关配置，使应用尽可能高效地运行。
优化器并不关心表使用的是什么存储引擎，但存储引擎对于查询优化是有影响的。优化器会向存储引擎询问它的一些功能、某个具体操作的成本，以及表数据的统计信息。例如，一些存储引擎支持对某些查询有帮助的特定索引类型。
//TODO 更多关于优化器的细节链接
//TODO 更多关于索引与schema优化的内容
Note
在旧版本中，MySQL可以使用内部查询缓存（query cache）来查看是否可以直接提供结果。但是，随着并发性的增加，查询缓存成为一个让人诟病的瓶颈。从MySQL 5.7.20版本开始，查询缓存已经被官方标注为被弃用的特性，并在8.0版本中被完全移除。