一条 SELECT 语句在 MySQL 中是如何执行的？—— 从 TCP 连接到结果返回的完整链路解析

引言

本文从底层视角详细解析了一条 SELECT 语句在 MySQL 中的完整执行流程，涵盖连接建立、查询缓存、SQL 解析、执行计划生成以及执行器与存储引擎的协作机制，深入解释了 MySQL 优化器的工作原理和关键设计取舍，适合作为理解 MySQL 内核执行机制和面试高频题的系统性参考。

为什么要搞懂 SELECT 的执行过程？

在日常开发中，我们几乎每天都在写SELECT语句，但大多数人只停留在“会写 SQL”这个层面：

SELECT * FROM user WHERE id = 1;

但在实际中，或者在性能优化、慢 SQL 排查、数据库异常分析时，更应该关心的是：

• MySQL是如何处理这条 SQL 的？
• SQL 在 MySQL 内部经历了哪些模块？
• 优化器是如何选择索引的？
• 为什么EXPLAIN能看到执行计划？
• 为什么 MySQL 8.0 直接移除了查询缓存？

理解一条 SELECT 的执行流程，是理解 MySQL 内核的起点。

整体执行流程总览

一条SELECT语句，在 MySQL 中大致会经历以下几个阶段：

1. 连接器（Connection）

2. 查询缓存（Query Cache，8.0 已移除）

3. 解析器（Parser）

   • 词法分析

   • 语法分析

4. 执行器阶段

   • 预处理（Prepare）

   • 优化（Optimize）

   • 执行（Execute）

下面我们按时间顺序逐层拆解。

第一步：连接器 —— 建立客户端与 MySQL 的连接

MySQL 是如何被连接的？

当你在 Linux 或 macOS 终端执行：

mysql -h 127.0.0.1 -u root -p

本质上发生了以下事情：

（1）TCP 三次握手

MySQL基于 TCP 协议通信，客户端与 MySQL Server 之间会先完成 TCP 三次握手：

客户端 -> SYN 服务端 -> SYN + ACK 客户端 -> ACK

连接成功后，才进入 MySQL 协议层。

（2）身份认证

连接器会做以下校验：

• 校验用户名
• 校验密码
• 校验来源主机
• 加载该用户的权限信息

这些权限信息会在连接建立时一次性读取。

⚠️重要细节

即使你在连接后修改了用户权限，这个连接内的权限也不会立刻生效，需要重新建立连接。

（3）连接管理

• 每个连接对应一个线程

• 连接数受max_connections控制

• 连接长期不释放，会导致连接资源浪费

第二步：查询缓存（Query Cache）—— 已被淘汰的设计

⚠️ MySQL 8.0已经彻底移除查询缓存

但理解它为什么失败，非常有价值。

查询缓存的设计思路

查询缓存采用Key-Value形式：

• Key：SQL 字符串（完全一致）

• Value：查询结果集

流程是：

收到 SQL → 判断是否命中缓存 → 命中：直接返回结果 → 未命中：继续执行 SQL

为什么查询缓存命中率极低？

举个例子：

SELECT * FROM user WHERE id = 1; SELECT * FROM user WHERE id=1;

哪怕只是一个空格不同，缓存都无法复用。

更致命的是：

• 只要表有任何一条数据发生变化
• 该表相关的缓存全部失效

在高并发、频繁写入的系统中：

查询缓存 = 缓存了个寂寞

为什么 MySQL 8.0 移除了它？

• 维护成本高
• 锁竞争严重
• 实际收益极低

结论：

查询缓存是一个“设计上很美好，实践中很失败”的功能。

第三步：解析器 —— SQL 是如何被“看懂”的？

解析器负责把字符串形式的 SQL，转成 MySQL 能理解的结构。

词法分析（Lexical Analysis）

将 SQL 字符流拆分成一个个Token。

示例 SQL：

SELECT name FROM user WHERE id = 1;

词法分析后大致得到：

语法分析（Syntax Analysis）

在词法分析的基础上，解析器会：

• 校验 SQL 是否符合 MySQL 语法规则
• 构建语法树（AST，Abstract Syntax Tree）

如果 SQL 不合法，例如：

SELEC name FROM user;

会直接在这一步报错：

You have an error in your SQL syntax

第四步：执行 SQL（核心）

真正“干活”的阶段，分为三步：

Prepare → Optimize → Execute

Prepare：预处理阶段

主要做静态检查：

• 表是否存在
• 字段是否存在
• 权限是否满足
• 将SELECT *展开为具体字段

例如：

SELECT * FROM user;

会被展开为：

SELECT id, name, age, email FROM user;

Optimize：优化器阶段（灵魂）

优化器做什么？

• 选择使用哪个索引
• 决定表的访问顺序
• 判断是否使用：

• 全表扫描

• 索引扫描

• 覆盖索引

成本模型

MySQL 优化器是基于成本（Cost）的：

• I/O 成本
• CPU 成本
• 预估扫描行数

最终选择成本最低的执行计划。

使用 EXPLAIN 查看执行计划

EXPLAIN SELECT * FROM user WHERE id = 1;

常见字段含义：

Execute：执行器阶段

执行器根据优化器生成的执行计划：

• 调用存储引擎接口（如 InnoDB）
• 按索引或全表扫描读取数据
• 逐行判断WHERE条件
• 返回结果给客户端

总结：一条 SELECT 的完整生命周期

客户端 ↓ TCP 连接 + 身份认证（连接器） ↓ 查询缓存（8.0 已移除） ↓ 解析器（词法 + 语法） ↓ 预处理（表、字段、权限） ↓ 优化器（选择索引、执行计划） ↓ 执行器（调用存储引擎） ↓ 返回结果