> SQL基础：SELECT执行流程

---

大家好，我是一名拥有10年以上经验的DBA老兵。

做这个系列，源于一个朴素的愿望：把踩过的坑、总结的经验系统化输出，希望能帮到刚入行或想进阶的兄弟们。

让我们开始今天的第8天内容。

---

> 🎯 **面试考点**

- SELECT 语句从输入到输出经历了哪些步骤？
- 查询缓存为什么在 MySQL 8.0 被移除了？
- 优化器是怎么选择索引的？
- 执行器是怎么获取数据的？

---

## 背景引入

> 💡 说白了：你以为 SELECT 只是查一下？其实它跑了半个数据库

你有没有想过：

- 你敲下 `SELECT * FROM user WHERE id = 1`，MySQL 到底做了什么？
- 为什么有时候明明加了索引，MySQL 却不用？
- 为什么同样的 SQL，有时候快有时候慢？

说实话，不理解 SELECT 执行流程的 DBA，就像不知道汽车怎么跑的司机——能开，但出了问题只能干瞪眼。

今天的目标：**搞懂 SELECT 语句的完整执行流程，面试必问**。

---

## 核心概念

### 执行流程全景图

![PixPin_2026-05-02_21-57-42.png](https://developer.qcloudimg.com/http-save/yehe-7512475/a0e0977ac8c159e52c4149c4b6b9d84f.png)
---

### 第一步：连接器

> 💡 **说白了**：连接器就是门卫，验明正身才让进

**职责**：
- 建立 TCP 连接
- 验证用户名密码
- 获取用户权限（后续操作都依赖这个权限）

**面试必问**：
- 为什么有时候连接很慢？
- 长连接和短连接有什么区别？
- 为什么长连接会导致内存泄漏？

> **面试解答**：

**Q: 为什么有时候连接很慢？**

> 因为建立 TCP 连接需要三次握手，如果数据库服务器距离远或者网络差，连接就会慢。建议使用连接池，复用连接。

**Q: 长连接和短连接有什么区别？**

> 短连接：每次执行完 SQL 就断开连接。长连接：执行完 SQL 后保持连接，下次复用。长连接减少了建立连接的开销，但会导致内存增长。

---

### 第二步：查询缓存（MySQL 8.0 已移除）

> 💡 **说白了**：查询缓存就是"抄作业"，SQL 完全一样就直接返回结果

**工作机制**：
1. 检查 SQL 是否命中缓存（精确匹配，包括空格）
2. 命中 → 直接返回结果
3. 未命中 → 继续执行后续步骤，结果放入缓存

**为什么 MySQL 8.0 移除了？**
- 缓存失效太频繁：表有任何更新，该表所有缓存失效
- 命中率低：业务 SQL 通常有参数差异
- 维护成本高：需要额外的锁机制

```sql
-- MySQL 5.7 可以手动关闭查询缓存
SET GLOBAL query_cache_type = 0;

-- 查看缓存状态
SHOW STATUS LIKE 'Qcache%';
```

---

### 第三步：解析器

> 💡 **说白了**：解析器就是"语文老师"，检查 SQL 语法对不对

**职责**：
- **词法分析**：识别关键字、表名、列名
- **语法分析**：检查 SQL 语法是否正确

```sql
-- 语法错误示例
SELEC * FROM user;  -- 报错：SELEC 不是有效关键字

-- 语义错误示例（解析器检查不出，在预处理器报错）
SELECT * FROM user WHERE non_exist_column = 1;  -- 如果列不存在，在预处理器报错
```

---

### 第四步：预处理器

> 💡 **说白了**：预处理器就是"班主任"，检查表和列是否存在

**职责**：
- 检查表名、列名是否存在
- 检查用户是否有权限访问这些表和列
- 展开 `SELECT *` 为具体列名

```sql
-- 预处理器会检查
SELECT * FROM user WHERE age > 18;

-- 等价于
SELECT id, name, age, ... FROM user WHERE age > 18;
```

---

### 第五步：优化器

> 💡 **说白了**：优化器就是"军师"，决定怎么执行最高效

**职责**：
- 选择使用哪个索引
- 决定表的连接顺序
- 选择最优的执行计划

**优化器的工作原理**：
```sql
-- 优化器会考虑以下因素
EXPLAIN SELECT * FROM user WHERE age > 18 AND city = '北京';

-- 优化器可能选择：
-- 方案1：使用 idx_age 索引，然后回表过滤 city
-- 方案2：使用 idx_city 索引，然后回表过滤 age
-- 方案3：使用联合索引 idx_age_city（如果存在）
```

**面试必问**：
- 优化器是基于什么选择索引的？
- 优化器选择错了怎么办？

> **面试解答**：

**Q: 优化器是基于什么选择索引的？**

> 基于统计信息（cardinality、数据分布等）估算成本，选择成本最低的执行计划。但统计信息可能不准确，导致优化器选错索引。

**Q: 优化器选择错了怎么办？**

> 可以使用 `FORCE INDEX` 强制指定索引，或者 `ANALYZE TABLE` 更新统计信息。

---

### 第六步：执行器

> 💡 **说白了**：执行器就是"干活的人"，真正去存储引擎取数据

**职责**：
- 根据执行计划，调用存储引擎的接口获取数据
- 对结果进行过滤、排序、聚合等处理

```sql
-- 执行器的工作流程
SELECT * FROM user WHERE age > 18;

-- 1. 调用存储引擎的索引接口，获取满足条件的记录ID
-- 2. 调用存储引擎的行读取接口，获取完整行数据
-- 3. 返回结果集给客户端
```

---

## 实战案例

### 场景一：查看 SELECT 执行流程

```sql
-- 开启性能监控
SET profiling = 1;

-- 执行查询
SELECT * FROM user WHERE id = 1;

-- 查看执行过程
SHOW PROFILES;
SHOW PROFILE FOR QUERY 1;
```

**输出示例**：
```
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000045 |
| checking permissions | 0.000006 |
| Opening tables       | 0.000015 |
| init                 | 0.000008 |
| System lock          | 0.000006 |
| optimizing           | 0.000004 |
| statistics           | 0.000012 |
| preparing            | 0.000008 |
| executing            | 0.000003 |
| Sending data         | 0.000035 |
| end                  | 0.000003 |
| query end            | 0.000002 |
| closing tables       | 0.000004 |
| freeing items        | 0.000015 |
| cleaning up          | 0.000003 |
+----------------------+----------+
```

---

### 场景二：优化器选错索引

```sql
-- 创建测试表
CREATE TABLE orders (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT,
    status VARCHAR(20),
    amount DECIMAL(10,2),
    create_time DATETIME,
    INDEX idx_user_id (user_id),
    INDEX idx_status (status),
    INDEX idx_create_time (create_time)
);

-- 插入数据（status 分布不均匀）
INSERT INTO orders (user_id, status, amount, create_time)
SELECT 
    FLOOR(RAND() * 10000),
    CASE WHEN RAND() < 0.9 THEN 'completed' ELSE 'pending' END,
    ROUND(RAND() * 1000, 2),
    DATE_ADD('2026-01-01', INTERVAL FLOOR(RAND() * 365) DAY)
FROM (
    WITH RECURSIVE cte AS (SELECT 1 AS n UNION ALL SELECT n+1 FROM cte WHERE n<100000)
    SELECT * FROM cte
) tmp;

-- 查看执行计划
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND create_time > '2026-06-01';

-- 优化器可能选错索引，强制指定
SELECT * FROM orders FORCE INDEX(idx_create_time) WHERE status = 'pending' AND create_time > '2026-06-01';
```

---

## 💡 AI 辅助实战

> 🤖 **AI 能不能帮我对比不同 SQL 写法的执行流程？**

能！让 AI 分析同一需求的不同写法，对比执行流程和性能差异：

```markdown
提示词示例：

"以下两种写法都能查询有订单的用户，请分析执行流程有什么区别：

写法1（子查询）：
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders)

写法2（JOIN）：
SELECT DISTINCT u.* FROM users u JOIN orders o ON u.id = o.user_id

请分析：
1. 两种写法的执行流程
2. 哪种写法性能更好
3. 什么场景下选择哪种写法"
```

**AI 分析结果**：

| 对比项 | 写法1（子查询） | 写法2（JOIN） |
|--------|----------------|---------------|
| 执行流程 | 先执行子查询，再用 IN 匹配 | 先 JOIN，再去重 |
| 索引使用 | 可能无法使用索引 | 可以使用索引 |
| 临时表 | 可能需要临时表 | 需要临时表去重 |
| 性能 | 数据量大时较慢 | 通常更快 |

**AI 优化建议**：
- 写法1 改成 EXISTS 或 JOIN
- 写法2 可以用 GROUP BY 代替 DISTINCT
- 都可以加索引优化

---

## 避坑指南

> ⚠️ 真实踩过的坑：

1. **不要迷信 EXPLAIN**
   - EXPLAIN 只是优化器的预估，一般不会有太大偏差，但它不是实际执行情况
   - 建议：用 `EXPLAIN ANALYZE`（MySQL 8.0+）看真实执行

2. **长连接要定期重置**
   - 长连接会导致内存增长（临时表、排序缓冲区等）
   - 建议：定期调用 `mysql_reset_connection()` 重置会话状态

   **C API 示例**：
   ```c
   MYSQL *conn = mysql_init(NULL);
   mysql_real_connect(conn, "localhost", "root", "", "test", 0, NULL, 0);
   
   mysql_query(conn, "SELECT * FROM user");
   
   // 重置连接（不断开，只清理会话状态）
   mysql_reset_connection(conn);
   ```

3. **优化器统计信息要定期更新**
   - 统计信息过期会导致优化器选错索引
   - 建议：定期执行 `ANALYZE TABLE`

---

## 思考题

> 🤔 互动时间：

1. 如果 SELECT 语句执行很慢，你会按什么顺序排查？
2. 为什么 MySQL 8.0 移除了查询缓存？
3. 优化器选错了索引，除了 `FORCE INDEX`，还有什么办法？

---

## 总结

> 🎯 **面试考点**

- **执行流程**：连接器 → 查询缓存 → 解析器 → 预处理器 → 优化器 → 执行器
- **连接器**：权限验证、长连接/短连接
- **查询缓存**：MySQL 8.0 已移除，因为失效频繁、命中率低
- **解析器**：词法分析、语法分析
- **优化器**：基于统计信息选择最优执行计划
- **执行器**：调用存储引擎获取数据

---

**下期预告**：WHERE子句优化技巧 —— 面试必问！
**全本合集**：[《每天一个MySQL知识点，百日打怪升级》](https://github.com/martianzhang/mysql_100_days)  
您的关注是我每日更新的动力(VX🌍)：没有那多

---

*有问题欢迎评论区交流，明天见！*



做这个系列，源于一个朴素的愿望：把踩过的坑、总结的经验系统化输出，希望能帮到刚入行或想进阶的兄弟们。

【第8天】每天一个MySQL知识点，百日打怪升级

本文系统解析MySQL中SELECT语句的完整执行流程：从连接器验权、（已移除的）查询缓存、解析器语法检查、预处理器语义校验，到优化器索引选择与执行器调用存储引擎取数。涵盖面试高频考点与实战避坑指南，助DBA深入理解SQL底层机制。（239字）

其他

深入了解SQL SELECT执行流程，从连接器到执行器的完整解析。掌握MySQL查询优化器工作原理、索引选择策略及常见性能问题排查方法。学习查询缓存移除原因、长连接管理技巧及优化器统计信息更新策略，提升数据库查询性能。

数据库

服务器

MySQL

腾讯云数据库特惠，新用户首单0.5折起


2026采购季 | AI焕新·智启新局

tencentdb-catalog

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【第8天】每天一个MySQL知识点，百日打怪升级-腾讯云开发者社区-腾讯云

【第8天】每天一个MySQL知识点，百日打怪升级

【第8天】每天一个MySQL知识点，百日打怪升级

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐