作者：微信小助手
发布时间：2025-02-26T09:29:48
在数据库的世界里，MySQL 凭借其高性能、高可靠性和易用性，成为了众多开发者和企业的首选。而在 MySQL 的日常使用中，查询性能优化是提升应用响应速度、保障用户体验的关键环节。今天，就让我们一同走进 MySQL 的 当我们向 MySQL 数据库发出一个查询请求时，数据库内部会经历一系列复杂的操作来返回结果。 要使用 执行这条语句后，MySQL 就不会真正去执行查询操作，而是返回关于这个查询的执行计划信息，以表格的形式呈现给我们。 这个字段告诉我们查询的类型，常见的有： 顾名思义，这个字段显示的是当前执行计划中正在访问的表名。如果查询涉及多个表的连接，这里就会依次列出每个表的信息。 这个字段显示的是查询中可能用到的索引。如果查询条件中涉及的列有索引，那么这些索引就会出现在这里。但需要注意的是， 当查询使用了索引进行等值连接时， 假设我们有一个名为 执行 从结果中可以看到， 优化方案：为 创建索引后，再次执行 此时， 我们有一个名为 执行 从结果中可以看到， 优化方案：创建一个复合索引，包含 创建索引后，再次执行 此时， MySQL 的 希望这篇文章能帮助你更好地理解和使用 MySQL 的 EXPLAIN 命令，它就像一把神奇的钥匙，能帮我们打开数据库查询性能的大门，让我们看清查询背后的执行逻辑，找到优化的突破口。一、初识 MySQL Explain
EXPLAIN 命令的作用，就是让我们能够看到这个查询在执行前，MySQL 是如何规划它的执行路径的，也就是所谓的执行计划。简单来说，EXPLAIN 就像是给数据库查询装上了一个 “透视镜”，让我们可以提前预知查询可能会遇到的问题，从而有针对性地进行优化。EXPLAIN，非常简单。只需要在你的 SQL 查询语句前加上 EXPLAIN 关键字，比如：EXPLAIN SELECT * FROM users WHERE age > 30;二、解读 Explain 的核心信息
EXPLAIN 返回的结果集包含了多个字段，每个字段都蕴含着重要的信息，下面我们就来逐一解读这些关键字段：1. id
id 是每个查询或子查询的唯一标识符。当查询比较简单时，可能只有一个 id 值；但如果查询涉及多个表的连接、子查询等情况，就会出现多个不同的 id。一般来说，id 值越大，表示该查询或子查询的执行优先级越高，先被执行。2. select_type
SIMPLE：简单的查询，不包含子查询和 UNION 操作。
PRIMARY：复杂查询中最外层的查询，如果查询中有子查询，这个值通常会出现在最外层查询中。
SUBQUERY：子查询，出现在 SELECT 或 WHERE 子句中的查询。
DERIVED：派生查询，也就是 FROM 子句中的子查询，MySQL 会将其结果作为一个临时表来处理。
UNION / UNION RESULT：用于 UNION 查询，UNION 表示参与 UNION 的查询，UNION RESULT 表示 UNION 查询的结果。
3. table
4. type
type 是一个非常关键的字段，它表示 MySQL 访问表的方式，也就是连接类型。不同的连接类型对查询性能有着巨大的影响，常见的连接类型从好到差依次为：
SYSTEM：系统表，非常快，因为数据量极少。
CONST：常量连接，查询条件是常量，可以直接定位到唯一一行数据。
EQ_REF：使用等值连接，并且连接条件的列上有索引，通常能高效地获取数据。
REF：非等值连接，或者等值连接但索引不是唯一索引，性能次于 EQ_REF。
RANGE：范围查询，比如 WHERE 子句中使用了 >、< 等条件，并且列上有索引，MySQL 会根据索引快速定位到一个数据范围。
INDEX：索引扫描，虽然使用了索引，但需要扫描整个索引树，性能不如上述几种连接类型。
ALL：全表扫描，性能最差，意味着 MySQL 要把表中的每一行数据都检查一遍，当数据量较大时，查询速度会非常慢。
5. possible_keys
possible_keys 只是表示可能用到的索引，并不一定就是实际用到的索引。6. key
key 字段显示的是查询实际使用的索引。如果这个字段为 NULL，说明查询没有使用索引，这可能是导致查询性能不佳的原因之一，需要我们重点关注并考虑是否需要创建合适的索引。7. key_len
key_len 表示查询实际使用的索引的长度。这个长度越短，通常意味着索引的选择性越好，查询性能也更优。通过这个字段，我们可以了解 MySQL 是如何使用索引的，以及索引的使用是否高效。8. ref
ref 字段会显示与索引列进行等值比较的列或常量。这个字段可以帮助我们了解查询条件是如何与索引配合使用的。9. rows
rows 字段估计了查询需要扫描的行数。这个估计值是 MySQL 根据统计信息和查询条件计算出来的，虽然不一定是精确值，但可以作为一个参考，帮助我们判断查询的大致性能。一般来说，扫描的行数越少，查询性能越好。10. filtered
filtered 表示经过查询条件过滤后，剩余数据的百分比。它的值范围是 0 到 100，值越高，说明查询条件过滤效果越好，返回的结果集越小，查询性能也更优。11. Extra
Extra 字段包含了一些额外的信息，这些信息往往对查询性能有着重要的影响。常见的值有：
Using index：表示查询使用了覆盖索引，即查询所需的数据全部都在索引中，不需要再访问表数据，这种情况下查询性能通常较好。
Using where：表示查询使用了 WHERE 子句进行过滤，这是正常的查询行为，但如果与其他信息结合分析，可以帮助我们了解查询的过滤效果。
Using join buffer：表示查询使用了连接缓冲区，这通常出现在连接类型为 REF 或 EQ_REF 的情况下，如果连接缓冲区使用较多，可能意味着连接操作比较复杂，需要关注查询性能。
Using filesort：表示查询使用了文件排序，这通常出现在需要对查询结果进行排序但没有合适的索引支持排序的情况下，文件排序会消耗较多的系统资源，对查询性能影响较大，需要尽量避免。
Using temporary：表示查询使用了临时表，这通常出现在复杂的查询中，如包含子查询、分组、排序等情况，使用临时表会增加查询的开销，需要关注查询性能。
三、实战案例：通过 Explain 优化查询
案例一：全表扫描引发的性能危机
orders 的表，存储了订单信息，表中有数百万条数据。现在我们需要查询某个客户的订单数量，执行了以下 SQL 语句：SELECT COUNT(*) FROM orders WHERE customer_id = 12345;EXPLAIN 后，结果如下：+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | orders| ALL | NULL | NULL | NULL | NULL | 1000000 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+type 为 ALL，说明这是一个全表扫描，possible_keys 和 key 都为 NULL，表示没有使用索引。rows 显示需要扫描 100 万行数据，这无疑会导致查询速度非常慢。customer_id 列创建索引。CREATE INDEX idx_customer_id ON orders(customer_id);EXPLAIN，结果如下：+----+-------------+-------+------+---------------+---------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+---------+---------+------+------+-------------+
| 1 | SIMPLE | orders| ref | idx_customer_id| idx_customer_id| 4 | const| 100 | Using index |
+----+-------------+-------+------+---------------+---------+---------+------+------+-------------+type 变为 ref，表示使用了索引进行等值连接，key 显示实际使用了 idx_customer_id 索引，rows 显示只需要扫描 100 行数据，查询性能得到了显著提升。案例二：文件排序的困扰
employees 的表，存储了员工信息，表中有几百万条数据。现在需要查询每个部门中工资最高的前 3 名员工，执行了以下 SQL 语句：SELECT department_id, employee_id, salary
FROM employees
WHERE department_id = 1
ORDER BY salary DESC
LIMIT 3;EXPLAIN 后，结果如下：+----+-------------+-------------+------+---------------+---------+---------+------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+------+---------------+---------+---------+------+------+-----------------------------+
| 1 | SIMPLE | employees | ref | idx_department_id | idx_department_id | 4 | const | 10000 | Using where; Using filesort |
+----+-------------+-------------+------+---------------+---------+---------+------+------+-----------------------------+Extra 字段出现了 Using filesort，说明查询使用了文件排序。虽然 type 为 ref，使用了 idx_department_id 索引，但由于没有合适的索引支持排序，导致需要进行文件排序，这会消耗较多的系统资源，影响查询性能。department_id 和 salary 列，以支持排序操作。CREATE INDEX idx_department_salary ON employees(department_id, salary DESC);EXPLAIN，结果如下：+----+-------------+-------------+------+---------------+---------------------+---------+------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+------+---------------+---------------------+---------+------+------+-----------------------------+
| 1 | SIMPLE | employees | ref | idx_department_salary | idx_department_salary | 8 | const | 3 | Using index |
+----+-------------+-------------+------+---------------+---------------------+---------+------+------+-----------------------------+Extra 字段变成了 Using index，表示查询使用了覆盖索引，不需要再访问表数据，查询性能得到了极大的提升。四、总结
EXPLAIN 命令是数据库查询性能优化的得力助手，通过解读 EXPLAIN 返回的执行计划信息，我们可以清晰地了解查询的执行路径、索引的使用情况以及可能存在的性能问题。在实际工作中，我们应该养成在编写 SQL 查询后，先使用 EXPLAIN 进行分析的习惯，及时发现并解决查询性能瓶颈，让我们的数据库应用更加高效、稳定。EXPLAIN 命令，在数据库优化的道路上更进一步。如果你有任何疑问或实践经验，欢迎在评论区留言交流，让我们共同探索 MySQL 的奥秘！