EXPLAIN SELECT ...;

或者更详细的格式：

EXPLAIN FORMAT=JSON SELECT ...;

输出列详解

1. ‌id‌

   • 数字标识符，表示查询中查询子句或表的顺序。较大的 id 通常表示更深层次的嵌套查询或子查询。
   • 如果 id 相同，则执行顺序由上至下；如果不同，id 越大优先级越高，通常表示被嵌套或子查询。

2. ‌select_type‌

   • 查询的类型，表明查询中每个 SELECT 子句的类型（或操作类型）。
   • 常见类型：
     • SIMPLE：简单的 SELECT 查询，查询中不包含子查询或 UNION。
     • PRIMARY：查询中最外层的 SELECT。
     • UNION：UNION 中的第二个或后续的 SELECT 语句。
     • DEPENDENT UNION：UNION 中的第二个或后续的 SELECT 语句，依赖于外部查询。
     • SUBQUERY：在 SELECT 或 WHERE 列表中包含了子查询。
     • DEPENDENT SUBQUERY：子查询，依赖于外部查询。
     • DERIVED：派生表的 SELECT 查询，即子查询在 FROM 子句中。

3. ‌table‌

   • 表名或别名，显示当前步骤所访问的表。
   • 有时显示为 derivedN（派生表）或临时表名。

4. ‌partitions‌

   • 匹配的分区信息（如果表有分区）。

5. ‌type‌

   • 连接类型或访问类型，表示 MySQL 在找到所需行时使用的访问方式。访问类型越高效，查询性能越好。
   • 常见类型：
     • system：表只有一行（特殊情况的 const）。
     • const：表最多有一个匹配行，用于主键或唯一索引比较。
     • eq_ref：对于每个从表行，从主表里读取一个行（最常见于主键或唯一索引）。
     • ref：非唯一索引扫描，返回所有匹配某个单值的行。
     • range：只检索给定范围的行，使用一个索引来选择行。
     • index：全表扫描，只是扫描索引树（比 ALL 快，因为通常索引比数据小）。
     • ALL：全表扫描，逐行操作，最慢的一种。

6. ‌possible_keys‌

   • 显示查询中能使用的索引。

7. ‌key‌

   • 实际使用的索引。如果为空，表示未使用索引。

8. ‌key_len‌

   • 使用的索引的长度（字节数）。长度越短，越高效。

9. ‌ref‌

   • 显示索引的哪一列或常量被用于查找值。

10. ‌rows‌

    • 估计为了找到所需的行而要读取的行数。这是一个估算值，并不总是准确。

11. ‌filtered‌

    • 显示估计的满足查询条件的行数百分比（针对存储引擎返回的行）。值越高，条件过滤效果越好。

12. ‌Extra‌

    • 包含不适合在其他列中显示但十分重要的额外信息。
    • 常见内容：
      • Using where：使用了 WHERE 条件来过滤行。
      • Using temporary：使用了临时表存储中间结果。
      • Using filesort：MySQL 需要额外的步骤来排序数据。
      • Using index：只通过索引树读取数据（索引覆盖），通常意味着高效查询。

使用 EXPLAIN 优化查询

通过分析 EXPLAIN 的输出，你可以识别查询中的潜在瓶颈，并采取相应的优化措施。例如：

• 确保查询使用了索引，尤其是主键和唯一索引。
• 避免全表扫描（ALL），尽量使用索引扫描（index、range、ref 等）。
• 优化 WHERE 条件，减少扫描的行数。
• 考虑重新设计表结构或索引，以提高查询效率。

示例

假设有一个简单的查询：

EXPLAIN SELECT * FROM employees WHERE department_id = 10;

EXPLAIN 输出可能如下：

+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table     | type  | possible_keys | key     | key_len | ref   | rows | Extra       |
+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------------+
|  1 | SIMPLE      | employees | ref   | dept_index    | dept_id | 4       | const |    1 | Using where |
+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------------+

从这个输出中，你可以看到查询使用了 ref 访问类型，并且使用了 dept_id 索引，扫描的行数估计为 1 行。

通过 EXPLAIN，你可以深入了解查询的执行细节，从而进行有效的优化。