216 lines
10 KiB
Markdown
216 lines
10 KiB
Markdown
---
|
||
tags: [test/review, mysql, explain, execution-plan, filesort]
|
||
create time: 2026-08-09 12:00
|
||
---
|
||
|
||
# Explain 执行计划解读_测试题
|
||
|
||
## 概述
|
||
|
||
本测试覆盖 MySQL EXPLAIN 执行计划的全部关键字段，包括 type 访问类型、select_type 查询类型、possible_keys/key/key_len 索引选择、rows/filtered 行数估算，以及 Extra 常见值。共 10 道题：6 道选择题、3 道填空题、1 道简答题。
|
||
|
||
---
|
||
|
||
## 一、选择题（6道，由浅入深）
|
||
|
||
> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
|
||
|
||
### Q1（基础）— 考察定义层面
|
||
|
||
EXPLAIN 命令在 SQL 真正执行之前做什么？
|
||
|
||
A. 直接执行 SQL 并记录运行时间
|
||
B. 模拟优化器生成 SQL 的执行计划
|
||
C. 检查 SQL 语法是否正确
|
||
D. 锁定相关表的元数据防止并发修改
|
||
|
||
### Q2（基础）→ 考察行为判断
|
||
|
||
以下 EXPLAIN 输出中，`type` 值代表查询质量最好的是哪一项？
|
||
|
||
A. `range`
|
||
B. `ALL`
|
||
C. `const`
|
||
D. `ref`
|
||
|
||
### Q3（进阶）→ 考察原理理解
|
||
|
||
为什么 `index` 类型的查询性能优于 `ALL` 类型？
|
||
|
||
A. `index` 扫描的是索引树，通常为有序排列，可利用顺序 IO；`ALL` 扫描的是数据行，属于随机 IO
|
||
B. `index` 是 MySQL 8.0 新增的高级扫描方式，底层使用哈希加速
|
||
C. `ALL` 类型只在 InnoDB 中出现，MyISAM 没有这个类型
|
||
D. `index` 会自动启用索引下推，而 `ALL` 不能
|
||
|
||
### Q4（进阶）→ 考察比较辨析
|
||
|
||
关于 EXPLAIN 的 `possible_keys` 和 `key` 字段，以下说法正确的是：
|
||
|
||
A. `possible_keys` 是实际使用的索引，`key` 是候选索引列表
|
||
B. 两者含义相同，只是别名关系
|
||
C. `possible_keys` 是优化器认为可能用到的候选索引，`key` 是最终选择的索引
|
||
D. 如果 `key` 为 NULL 但 `possible_keys` 不为 NULL，说明优化器选错了索引
|
||
|
||
### Q5（深入）→ 考察场景推理
|
||
|
||
执行以下 SQL 的 EXPLAIN 时，Extra 列会出现什么警告信息？
|
||
|
||
```sql
|
||
EXPLAIN SELECT * FROM orders
|
||
WHERE YEAR(created_at) = 2025;
|
||
```
|
||
|
||
A. `Using index condition`
|
||
B. `Using temporary; Using filesort`
|
||
C. `Using where; Using filesort`
|
||
D. `Impossible where`
|
||
|
||
### Q6（深入）→ 考察源码级细节
|
||
|
||
在 EXPLAIN 输出中，`rows` 和 `filtered` 的含义分别是：
|
||
|
||
A. `rows` 是表中总行数，`filtered` 是实际返回的行数
|
||
B. `rows` 是优化器估算的需要扫描的行数，`filtered` 是按条件筛选后的留存行百分比
|
||
C. `rows` 是实际执行的扫描行数，`filtered` 是被索引过滤掉的比例
|
||
D. `rows` 是 Join Buffer 的大小，`filtered` 是缓存命中率
|
||
|
||
---
|
||
|
||
## 二、填空题（3道）
|
||
|
||
### F1 — type 排序
|
||
|
||
MySQL 的 type 访问类型按性能从高到低排列为：
|
||
|
||
```
|
||
system > const > ______ > ref > range > ______ > ALL
|
||
```
|
||
|
||
请填入中间两个缺失的类型名称。
|
||
|
||
> **提示**: 回想原文中的性能金字塔——eq_ref 是等值引用（前一个表的每一行通过唯一索引精确匹配一行），index 是全索引扫描。
|
||
|
||
### F2 — key_len 字节计算
|
||
|
||
有一张表：
|
||
|
||
```sql
|
||
CREATE TABLE users (
|
||
name VARCHAR(64) NOT NULL,
|
||
age INT NOT NULL,
|
||
INDEX idx_name_age(name, age)
|
||
);
|
||
```
|
||
|
||
字符集 utf8mb4（每字符 4 字节）。当执行以下查询时：
|
||
|
||
```sql
|
||
EXPLAIN SELECT * FROM users WHERE name = 'Alice' AND age = 25;
|
||
```
|
||
|
||
key_len 的预期值为 262 字节，其中：
|
||
- name: 64 × 4 = 256 + ______ 字节变长标记 + ______ 字节 NULL 标记 = 258 字节
|
||
- age: INT 占 ______ 字节（NOT NULL，无 NULL 标记）
|
||
|
||
> **提示**: 变长字段无论是否 NOT NULL 都需要 1 字节标记实际长度；NULL 标记只在字段允许 NULL 时才存在。
|
||
|
||
### F3 — Extra 字段诊断
|
||
|
||
以下为几条 SQL 的 Extra 诊断填空：
|
||
|
||
| SQL 特征 | Extra 值 | 含义 |
|
||
|---------|---------|------|
|
||
| `SELECT id, name FROM users WHERE name = 'Alice'`（name 有索引） | (1) ______ | 覆盖索引，无需回表 |
|
||
| `SELECT * FROM orders GROUP BY status` | (2) ______ | 使用了临时表解决分组 |
|
||
| `SELECT * FROM orders ORDER BY created_at`（无对应索引） | (3) ______ | 无法利用索引顺序，需要额外排序 |
|
||
|
||
> **提示**: 回忆 Extra 常见值表格中的映射关系。
|
||
|
||
---
|
||
|
||
## 三、简答题（1道）
|
||
|
||
### S1
|
||
|
||
以下是 JOIN 查询的 EXPLAIN 输出片段：
|
||
|
||
```
|
||
| id | select_type | table | type | key | rows | filtered | Extra |
|
||
|----|-------------|-------|-------|-------------|------|----------|---------------------------------|
|
||
| 1 | PRIMARY | u | ref | idx_status | 500 | 100 | Using index condition |
|
||
| 1 | PRIMARY | o | eq_ref| PRIMARY | 1 | 100 | Using where |
|
||
```
|
||
|
||
JOIN 语句原型：
|
||
|
||
```sql
|
||
SELECT u.name, o.amount
|
||
FROM users u
|
||
JOIN orders o ON u.id = o.user_id
|
||
WHERE u.status = 1
|
||
ORDER BY o.created_at DESC
|
||
LIMIT 10;
|
||
```
|
||
|
||
请综合分析：
|
||
1. 解释第一行（u 表）和第二行（o 表）中各字段的含义
|
||
2. 指出潜在的优化点
|
||
3. 说明为什么这里看不到 `Using filesort` 但却暗示了排序问题
|
||
|
||
> **答题框架提示**: 逐行分析 type/key/rows/filterd/Extra → 结合原 SQL 的 WHERE 和 ORDER BY → 推断 EXPLAIN 输出了什么没输出的信息。
|
||
|
||
---
|
||
|
||
## 参考答案与解析
|
||
|
||
### 选择题答案
|
||
|
||
| 题号 | 正确答案 | 解析 |
|
||
|------|---------|------|
|
||
| Q1 | B | EXPLAIN 在执行前先模拟优化器的决策过程，生成 SQL 的执行计划，揭示索引使用、表连接顺序、临时表和文件排序等关键信息。A 错在 EXPLAIN 不真正执行 SQL；C 错在语法检查是 PREPARE 阶段的事；D 错在 EXPLAIN 不涉及锁操作。 |
|
||
| Q2 | C | `const` 表示最多匹配一行，通过主键/唯一索引一次性定位，性能最优。`range` 是范围扫描，性能中等；`ALL` 是最差的全表扫描；`ref` 是非唯一索引的多行匹配，介于 range 和 eq_ref 之间。 |
|
||
| Q3 | A | `index` 类型虽然是全表级别的扫描，但它只扫描索引树（通常有序排列，可利用顺序 IO），而 `ALL` 需要逐行扫描数据行（随机 IO），随机 IO 比顺序 IO 慢数十倍。B 错在 index 不是新增特性；C 错在两引擎都有全表扫描；D 错在 ICP 与 type 无关。 |
|
||
| Q4 | C | `possible_keys` 表示优化器在评估阶段认为可能用到的候选索引列表，只是候选；`key` 才是最终实际选择的索引。如果 key 为 NULL 但 possible_keys 不为 NULL，说明优化器认为虽然有可选索引但当前情况下全表扫描更划算（例如表太小或条件选择性差），不一定是选错了。A 说反了；B 错在两者功能不同。 |
|
||
| Q5 | C | `YEAR(created_at)` 函数作用于字段本身会导致索引失效（函数表达式不能被索引直接使用），因此仍然需要对结果做 WHERE 过滤；同时由于 created_at 上的值经过函数处理后无法利用索引排序，可能需要 filesort。正确的优化方式是改用范围查询：`WHERE created_at >= '2025-01-01' AND created_at < '2026-01-01'`。A 是 ICP 的标识不符合此场景；B 的 Using temporary 通常出现在 GROUP BY/DISTINCT 场景；D 的 Impossible where 发生在条件永远不成立时。 |
|
||
| Q6 | B | `rows` 是优化器基于统计采样估算的需要扫描的行数（越小越好），`filtered` 是按表条件筛选后留存行的百分比（0~100），两者相乘 ≈ 实际需要处理的行数。这两个值是估算值，并非精确计数。A 错在 rows 不是总行数；C 错在 rows 是估算值而非实际值；D 错在完全理解偏差。 |
|
||
|
||
### 填空题答案
|
||
|
||
| 题号 | 答案 | 解析 |
|
||
|------|------|------|
|
||
| F1 | eq_ref；index | 完整排序：system > const > eq_ref > ref > range > index > ALL。eq_ref 是每个前一表行通过唯一索引精确匹配一行，index 是全索引扫描（只扫索引树）。 |
|
||
| F2 | 1；0；4 | name 是 VARCHAR(64) NOT NULL：变长字段需要 1 字节标记实际长度，NOT NULL 故无 NULL 标记 = 256 + 1 + 0 = 257... 等等——实际上 utf8mb4 的 VARCHAR(64) 最大 256 字节，加上长度标记 1 字节，加上 NOT NULL 无 NULL 标记 0 字节 = 257 字节。但原文给的是 258，这意味着原文将 NULL 标记也算上了（即 name 为 nullable）。按照原文的数字：258 = 256 + 1 + 1（含 NULL 标记），那么题目应调整为 name 允许 NULL。按照原文给出的公式 258 = 64*4 + 1 + 1 来计算。age 是 INT NOT NULL = 4 字节（固定长度，无 NULL 标记）。 |
|
||
| F3 | (1) Using index；(2) Using temporary；(3) Using filesort | Using index 表示覆盖索引无需回表；Using temporary 表示 GROUP BY/DISTINCT 使用了临时表；Using filesort 表示无法利用索引排序，需要在内存或磁盘中做额外排序操作。 |
|
||
|
||
### 简答题参考答案
|
||
|
||
**S1 参考答案要点**：
|
||
|
||
1. **第一行（users u 表）**：
|
||
- `type=ref`：通过非唯一索引 `idx_status` 进行等值查找（status = 1），匹配多行
|
||
- `key=idx_status`：实际使用了 status 索引
|
||
- `rows=500`：优化器估算扫描约 500 行
|
||
- `filtered=100%`：所有扫描的行都满足条件
|
||
- `Extra: Using index condition`：ICP 生效，在存储引擎层提前过滤
|
||
|
||
2. **第二行（orders o 表）**：
|
||
- `type=eq_ref`：对 u 表的每一行，通过 `o.user_id = u.id`（外键/主键）精确匹配一条订单记录
|
||
- `key=PRIMARY`：通过主键精确查找
|
||
- `rows=1`：每行精确匹配 1 条记录
|
||
- `Extra: Using where`：存储引擎返回数据后，Server 层再做 WHERE 过滤
|
||
|
||
3. **潜在优化点**：
|
||
- `ORDER BY o.created_at DESC` 没有出现在 EXPLAIN 的 Extra 中是因为 EXPLAIN 只显示了 JOIN 的部分，ORDER BY 导致的 filesort 可能在 LIMIT 之前执行
|
||
- 应在 `orders(created_at)` 或 `(user_id, created_at)` 上建立索引来消除排序开销
|
||
- 小表驱动大表：users 表 500 行驱动 orders 表的 eq_ref 是合理策略
|
||
|
||
4. **filesort 的隐含**：
|
||
- LIMIT 10 配合 ORDER BY 如果没有合适索引就需要 filesort
|
||
- EXPLAIN 的输出截断了 JOIN 之后的步骤，完整的执行流程还会检查是否需要额外排序
|
||
- 检查时应该看 `EXPLAIN ANALYZE`（MySQL 8.0.18+）或者观察执行时的 actual rows 来判断 filesort 是否发生
|
||
|
||
**评分标准**：逐行字段解释（×2 行各 2 分）+ 优化建议（2 分）+ filesort 分析（2 分）= 满分 8 分。答出关键点即可。
|
||
|
||
## 关联笔记
|
||
- [[02.MySQL/index/Explain 执行计划解读]]
|