MySQL EXPLAIN 详解：如何阅读执行计划并优化 SQL 查询

1. 什么是 MySQL EXPLAIN？为什么要使用它？

什么是 EXPLAIN？用于可视化执行计划的命令

在 MySQL 中，EXPLAIN 是一个用于可视化 SQL 查询执行方式的命令。它特别有助于理解 SELECT 语句中数据的检索方式，并显示查询的 执行计划。

例如，在执行类似 SELECT * FROM users WHERE age > 30 的查询时，EXPLAIN 让你看到内部细节，如 MySQL 使用了哪个索引以及表的扫描顺序。

使用方法很简单——只需在查询前加上 EXPLAIN。

EXPLAIN SELECT * FROM users WHERE age > 30;

以这种方式编写后，将显示描述查询执行计划的多列。每个项目将在后续章节中详细解释。

为什么要使用它：让慢查询原因可见

许多开发者常犯的错误是认为“只要 SQL 能运行，就没有问题”。然而，慢查询执行会对整体应用性能产生负面影响。

在处理大量数据的系统中，即使是单个低效查询也可能成为瓶颈，并给服务器带来显著负载。

这时 EXPLAIN 就显得极其有用。通过审查执行计划，你可以清晰地看到是否在进行全表扫描，或索引是否被正确使用。

换句话说，使用 EXPLAIN 可以识别性能瓶颈并确定如何优化。尤其是索引的有效性，在分析 EXPLAIN 输出时会更加清晰。

EXPLAIN 支持的 SQL 语句（SELECT、UPDATE 等）

EXPLAIN 不仅适用于 SELECT 语句，还支持以下 SQL 语句：

• SELECT
• DELETE
• INSERT
• REPLACE
• UPDATE

例如，在对大数据集执行 DELETE 语句时，如果索引未被正确使用，MySQL 可能会进行全表扫描，从而显著增加执行时间。为防止此类问题，在执行 DELETE 或 UPDATE 语句前使用 EXPLAIN 检查执行计划是非常有效的做法。

根据你的 MySQL 版本，你还可以使用 EXPLAIN ANALYZE，它提供更详细的执行信息。此内容将在本文后面介绍。

2. 理解 EXPLAIN 输出列（附示意图）

基本输出列的列表与解释

EXPLAIN 输出包括以下列（根据 MySQL 版本略有差异）：

其中，性能调优最重要的四列是 type / key / rows / Extra。

如何阅读四个关键列：type / key / rows / Extra

1. type（访问方式）

此列指示 MySQL 如何访问表。它直接影响性能。

如果 type = ALL，表示未使用索引，扫描所有行——这是最慢的访问方式。理想情况下，你应将查询优化为使用 ref 或 const。

2. key（使用的索引）

此列显示实际使用的索引名称。
如果为空，说明查询可能未使用索引。

3. rows（估计扫描的行数）

此列显示 MySQL 估计将要扫描的行数。数字越大，执行时间往往越长。目标是将查询优化，使 rows 尽可能接近 1。

4. Extra（附加信息）

Extra 列包含诸如排序操作或临时表使用等附加细节。

如果看到 Using temporary 或 Using filesort，应检查你的 SQL 语句或索引设计。

[Illustration] 示例 EXPLAIN 输出

EXPLAIN SELECT * FROM users WHERE age > 30;

在此示例中，尽管存在索引（age_index），但实际上未被使用，导致 ALL（全表扫描）。这表明还有优化空间。

3. 通过示例学习：如何使用 EXPLAIN 并解释结果

示例 1：简单 SELECT 查询的 EXPLAIN 输出（带解释）

让我们从单表的简单 SELECT 查询开始。

EXPLAIN SELECT * FROM users WHERE age > 30;

假设 EXPLAIN 输出如下：

解释：

• type: ALL → 全表扫描。未使用索引。
• key: NULL → 实际上未使用索引。
• rows: 5000 → MySQL 估计将扫描约 5,000 行。

如何改进：

通过在 age 列上添加索引，可以显著提升查询性能。

CREATE INDEX idx_age ON users(age);

如果再次运行 EXPLAIN，你应该会看到 type 变为 range 或 ref，这表明索引已被使用。

示例 2：分析带 JOIN 查询的 EXPLAIN 输出

接下来，让我们看一个连接多个表的示例。

EXPLAIN
SELECT orders.id, users.name
FROM orders
JOIN users ON orders.user_id = users.id
WHERE users.age > 30;

示例输出：

解释：

• users 表正在进行全表扫描（ALL），因此这是需要改进的部分。
• 与此同时，orders 表使用了 ref 索引，效率较高。

优化要点：

• 在 users.age 上添加索引可以加快对 users 表的扫描。
• 关键是设计索引，使 WHERE 子句能够在 JOIN 之前过滤行。

当索引未被使用（坏示例 → 好示例）

坏示例：WHERE 子句使用函数

SELECT * FROM users WHERE DATE(created_at) = '2024-01-01';

使用这样的查询时，索引会失效，因为 DATE() 函数会转换列值，导致 MySQL 无法高效使用索引。

改进示例：在不使用函数的情况下指定范围

SELECT * FROM users
WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02';

这使得 created_at 列的索引能够生效，从而让 MySQL 高效检索数据。

结论：使用真实的 EXPLAIN 示例诊断性能

通过分析真实查询中的 EXPLAIN 输出，你可以清晰地识别 瓶颈所在以及如何进行优化。

• ALL → 全表扫描。考虑添加或调整索引。
• key = NULL → 索引未使用。需要调查。
• Extra 包含 Using temporary → 性能警告。
• 在条件中使用函数或计算会导致索引失效。

牢记这些要点，将帮助你持续使用 EXPLAIN 改进查询性能。

4. 基于 EXPLAIN 结果的实用查询优化技术

避免 “type: ALL” 的索引设计基础

如果 EXPLAIN 显示 type: ALL，意味着 MySQL 正在执行全表扫描。这是一项非常昂贵的操作，对包含数千至数百万行的表来说会成为主要瓶颈。

如何避免：

• 为 WHERE 子句中使用的列添加索引

  CREATE INDEX idx_age ON users(age);
  

• 如果有多个条件，考虑使用复合索引

  CREATE INDEX idx_status_created ON orders(status, created_at);
  

• 避免不以固定前缀开始的 LIKE 模式

  -- Bad example (index won’t work)
  WHERE name LIKE '%tanaka%'
  
  -- Good example (index may work)
  WHERE name LIKE 'tanaka%'
  

“Extra: Using temporary” 的含义及解决方法

如果 Extra 列显示 “Using temporary”，意味着 MySQL 在内部创建临时表来处理查询。这通常发生在 GROUP BY 或 ORDER BY 等操作无法仅通过索引完成时，MySQL 必须使用临时存储手动组织数据。

解决方法：

• 为 GROUP BY 和 ORDER BY 中使用的列添加索引

  CREATE INDEX idx_group_col ON sales(department_id);
  

• 删除不必要的排序或 GROUP BY 语句
• 使用 LIMIT 或子查询来减少目标数据量

了解 “rows” 与 “key” 如何帮助你提升性能

rows 列表示 MySQL 预测需要从表中读取的行数。例如，查询显示 rows = 100000 时，性能可能会受到显著影响。

当该值很大时，你通常需要 应用能够减少扫描行数的索引 或 重写条件。

另一方面，key 列显示实际使用的索引。如果它为 NULL，则意味着没有使用索引，这是一个警告。

优化检查清单：

• 如果 rows 很大 → 你的过滤条件有效吗？索引是否被正确使用？
• 如果 key = NULL → 你的 WHERE/JOIN 中是否使用了导致索引失效的模式？

将 EXPLAIN 与优化养成习惯

要有效调优查询，基本做法是重复以下循环：编写 → 使用 EXPLAIN 检查 → 改进 → 再次检查。

请记住以下工作流程：

1. 正常编写查询
2. 使用 EXPLAIN 检查执行计划
3. 查看 type、key、rows 和 Extra
4. 若出现瓶颈，修改索引或重写查询
5. 再次运行 EXPLAIN 以确认改进

查询性能不仅受索引影响，还受 查询本身的写法 影响。使用简单的比较（而非函数）和直接的条件往往能带来意想不到的效果。

5. 使用 MySQL Workbench Visual EXPLAIN 进行可视化分析

使用 GUI 工具可视化检查执行计划

MySQL Workbench 是专为 MySQL 管理和开发设计的 GUI 工具。它最大的优势之一是能够 可视化显示执行计划，这在终端输出中往往难以阅读。

通过 Visual EXPLAIN，你可以在 树形结构 中查看以下信息：

• 每个表的访问顺序
• 使用的 JOIN 类型
• 索引使用情况
• 是否发生全表扫描
• 数据过滤和排序操作

由于计划以图形方式展示，即使是初学者也能更容易地识别性能瓶颈所在。

[With Images] 如何使用和阅读 Visual EXPLAIN（分步指南）

按照以下步骤使用 Visual EXPLAIN：

1. 启动 MySQL Workbench 并打开你的数据库连接 → 确保连接已预先配置。
2. 在 SQL 编辑器中输入目标查询

   SELECT * FROM users WHERE age > 30;
   

3. 点击 EXPLAIN 按钮旁的 “EXPLAIN VISUAL” 图标 → 或右键点击并从菜单中选择 “Visual Explain”。
4. 执行计划将以可视化方式显示 当你点击每个节点（表）时，会出现如下详细信息：

• 访问方式（ALL、ref、range 等）
• 使用的索引
• 估计行数（rows）
• 过滤条件和 JOIN 方法

注意：
在 Visual EXPLAIN 中，节点的颜色和图标用于突出 耗时操作或低效部分。请特别关注标记为红色的节点，因为它们通常表示性能问题。

初学者也能轻松找出瓶颈

基于文本的 EXPLAIN 输出起初可能让人感到压倒，但 Visual EXPLAIN 能让 问题区域以视觉方式突出。

例如，它可以更容易地帮助你识别：

• 使用 type: ALL 的表
• 显示 Using temporary 的查询块
• 不必要的 JOIN 模式
• 未使用索引的表

借助其 GUI 界面，你可以快速形成优化假设，而且它对 在团队内部共享和审查 SQL 性能 也非常有用。

Visual EXPLAIN 对于初学者到中级 SQL 用户尤为有价值。
如果你不确定如何解释 EXPLAIN 结果，尝试使用此功能吧。

6. 常见问题解答 (FAQ)

Q1. 何时应该使用 EXPLAIN？

A. 当你对查询的执行速度感到不确定时——尤其是当查询“感觉慢”时——应该使用 EXPLAIN。它在你想验证新建查询是否 正确使用索引 时也非常有用。

通过在部署前检查执行计划，你可以 提前识别性能风险。

Q2. 输出显示 type = ALL。我该怎么办？

A. type: ALL 表示 MySQL 正在进行全表扫描。这是一种高成本操作，尤其在大表上会显著降低性能。

考虑以下措施：

• 为 WHERE 子句中使用的列添加索引
• 避免会禁用索引使用的函数或操作
• 避免 SELECT *，只检索必要的列

Q3. Extra 列中的 “Using temporary” 是问题吗？

A. Using temporary 表示 MySQL 在内部创建临时表来处理查询。这通常出现在 GROUP BY 或 ORDER BY 时，可能会增加内存和磁盘 I/O 开销。

可能的解决方案包括：

• 为 GROUP BY / ORDER BY 中使用的列添加索引
• 减少不必要的排序或聚合
• 使用 LIMIT 或子查询来缩小数据集

Q4. 我该如何使用 Visual EXPLAIN？

A. 你可以使用官方的 MySQL 工具 MySQL Workbench，在 GUI 中 可视化 EXPLAIN 结果。只需输入查询并点击 “Visual Explain” 按钮。

这尤其适用于：

• 觉得基于文本的 EXPLAIN 输出难以阅读的用户
• 想直观了解复杂 JOIN 的人
• 团队一起审查 SQL 性能时

Q5. 为什么我的索引已经存在却没有被使用？

A. 即使索引已存在，MySQL 并不一定会使用它。以下情况可能导致索引被忽略：

• 在 WHERE 子句中使用函数或表达式（例如 WHERE YEAR(created_at) = 2024）
• 基数低（值分布不均），全表扫描可能更快
• 复合索引的列顺序与查询不匹配

要确认索引是否被正确使用，始终检查 EXPLAIN 中的 key 列。

7. Summary: Use EXPLAIN to Discover SQL Optimization Opportunities

MySQL 的性能调优不仅仅是添加索引。
识别 哪些查询是瓶颈、为何慢以及如何修复 的关键工具就是 EXPLAIN。

在本文中，我们覆盖了以下要点：

✅ The Role and Basic Usage of EXPLAIN

• 只需在查询前加上 EXPLAIN 即可查看执行计划
• 全表扫描（ALL）和 Using temporary 等问题一目了然

✅ How to Read Output Columns and Evaluate Performance

• 最重要的四列是 type、key、rows 和 Extra
• 避免全表扫描，争取正确使用索引
• 看到 Using temporary 或 Using filesort 时要格外留意

✅ Practical Diagnosis and Optimization Through Real Examples

• 不仅要添加索引，还要改进 SQL 语法
• 即使是包含 JOIN 或子查询的复杂查询，也可以通过 EXPLAIN 进行分析
• 基于执行计划持续优化查询是提升性能的最快途径

✅ Use GUI Tools for Visual Confirmation

• 在 MySQL Workbench 中使用 “Visual EXPLAIN” 以图形方式查看执行计划
• 对初学者来说，更容易直观识别瓶颈
• 有助于团队讨论和 SQL 性能评审

✅ FAQ Coverage for Real-World Scenarios

• 解释了 type=ALL、key=NULL 等问题的原因及解决方案
• 提供了索引未被使用的示例

✍️ Make EXPLAIN a Habit to Improve Your SQL Skills

如果你养成每次编写 SQL 时都使用 EXPLAIN 检查的习惯，你自然会写出 更快、更高效的查询。

这不仅是技术技巧——它是培养专业 SQL 素养的一部分。

• 在编写查询后立即运行 EXPLAIN
• 立即修复可疑的执行计划
• 深思熟虑地设计高效索引

通过掌握这一循环，您的 MySQL 技能将稳步提升。

我们希望本文能成为您迈向更佳查询优化的第一步。

如果您有任何疑问或希望我们覆盖其他主题，欢迎随时留言！