一文读懂一条 SQL 查询语句是如何执行的

2001 年 MySQL 发布 3.23 版本，自此便开始获得广泛应用，随着不断地升级迭代，至今 MySQL 已经走过了 20 个年头。
为了充分发挥 MySQL 的性能并顺利地使用，就必须正确理解其设计思想，因此，了解 MySQL 的逻辑架构是必要的。本文将通过一条 SQL 查询语句的具体执行过程来详细介绍 MySQL 架构中的各个组件。
MySQL 最重要、最与众不同的特性就是它的可插拔存储引擎架构（pluggable storage engine architecture），这种架构的设计将查询处理及其他系统任务和数据的存储/提取分离开来。来看官方的解释：
The MySQL pluggable storage engine architecture enables a database professional to select a specialized storage engine for a particular application need while being completely shielded from the need to manage any specific application coding requirements.
大致意思就是， MySQL 可插拔存储引擎架构使开发者能够为特定应用程序需求选择专门的存储引擎，同时完全无需管理任何特定应用程序编码要求。也就是说，尽管不同存储引擎具有不同的功能，但应用程序不受这些差异的影响。
如果应用程序更改带来了需要更改底层存储引擎的需求，或者需要添加一个或多个存储引擎来支持新需求，则无需进行重大的编码或流程更改即可使工作正常进行。MySQL 服务器架构通过提供适用于跨存储引擎的一致且易于使用的 API ，使应用程序免受存储引擎底层复杂性的影响。
MySQL 的逻辑架构图如下，参考《高性能 MySQL - 第 3 版》：

本文插图
我们可以大致把 MySQL 的逻辑架构分成 Server 层和存储引擎层：
1）大多数 MySQL 的核心服务功能都在 Server 层，包括连接，查询解析、分析、优化、缓存以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。
值得一提的是， Server 最上面的服务也就是连接器，拥有管理 MySQL 连接、权限验证的功能。显然这并非 MySQL 所独有，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构。
2）第二层就是存储引擎（支持 InnoDB、MyISAM、Memory 等多个存储引擎）。存储引擎负责 MySQL 中数据的存储和提取，响应上层服务器的请求。每个存储引擎自然是有它的优势和劣势，不同的存储引擎之间无法相互通信，所以我们需要根据不同的场景来选择合适的存储引擎。
服务器通过 API 与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎 API 包含几十个底层函数，用于执行诸如 “开始一个事务” 或者 “根据主键提取一行记录” 等操作。