MySQL EXPLAIN 详解：理解 Type、Key 与 Extra 字段优化查询

核心字段：Type（访问类型）

type 字段表示 MySQL 引擎查找表数据的方式，直接反映了查询的效率。该字段的性能通常遵循以下递减顺序：const > eq_ref > ref > range > index > ALL。理解每种类型的触发条件，是优化查询的第一步。

第1步：All - 全表扫描

这是效率最低的一种类型。MySQL 需要遍历整张表的所有行来寻找匹配记录。当查询没有使用索引时，极容易出现此类型。

触发场景：无索引的查询。
示例代码：

mysql> explain select * from dept_emp;

结果分析：

• type: ALL
• rows: 显示扫描的行数（如 331570），数值越大性能越差。

第2步：Index - 全索引扫描

比 ALL 高效，但并非最优。MySQL 会扫描整个二级索引树来获取数据。通常发生在查询字段本身就是索引列，且没有 WHERE 子句限制时。

示例代码：

mysql> explain select dept_no from dept_emp;

结果分析：

• type: index
• Extra: 可能出现 Using index，表示使用了覆盖索引，无需回表。

第3步：Range - 区间扫描

针对范围查询（如 <, >, BETWEEN）。仅扫描满足条件的索引范围，效率高于全索引扫描。

示例代码：

mysql> explain select * from dept_emp where emp_no > 7;

结果分析：

• type: range
• key: 显示具体使用的索引名称（如 PRIMARY）。

第4步：Ref - 非唯一索引查找

常用于 = 或 <=> 操作符，且查询字段为非唯一索引的单表或多表连接。

示例代码（单表）：

mysql> explain select * from dept_emp where dept_no = 'd005';

结果分析：

• type: ref
• ref: 显示比较的常量值或其他表的列。

第5步：Eq_ref - 唯一索引查找

最高效的非常数查找方式。通常在多表连接中使用，前驱表返回的每一行，在后表中能通过唯一索引查找到精确的一条记录。

示例代码：

mysql> explain select * from departments, dept_desc 
where departments.dept_name = dept_desc.dept_name;

结果分析：

• type: eq_ref（出现在 departments 表中）。
• ref: 引用另一张表的列作为索引查找依据。

第6步：Const - 常量查找

当通过主键或唯一索引进行等值查询时出现。由于条件唯一，MySQL 只需扫描极少数据甚至不需要读取表即可确定结果，效率极高。

示例代码：

mysql> explain select * from departments where dept_no = 'd005';

结果分析：

• type: const
• ref: const，表示与常量比较。

注意： type 仅反映访问效率，不代表最终执行速度。若 range 查询涉及大量回表操作，其耗时可能超过不引起回表的 index 扫描。

辅助字段：Key 与 Extra

除了 type，key 和 extra 字段提供了更深层的执行细节。

Key：实际使用的索引

显示 MySQL 决定使用的确切索引。若希望强制使用特定索引，可在 SQL 中加入 FORCE INDEX (index_name)；若想忽略索引，可使用 IGNORE INDEX (index_name)。

Extra：关键执行状态信息

Extra 包含许多影响性能的重要标志：

• Using index：覆盖索引。查询所需的列都在索引树中，无需回表查询数据行，性能极佳。
• Using where：存储引擎无法通过索引过滤所有数据，需要服务器层进行 WHERE 过滤，或者未使用索引。
• Using index condition (ICP)：索引下推。MySQL 5.6+ 特性，在存储引擎层尝试利用索引部分过滤行，减少回表次数。
• Using filesort：文件排序。MySQL 无法利用索引完成排序，需要在内存或磁盘上进行额外排序，通常会降低性能。
• Using temporary：创建临时表。MySQL 在处理查询时需要建立临时表来保存中间结果（常见于 GROUP BY 或 ORDER BY），严重影响性能。

排错与优化建议

在实际排查中，可能会遇到一些特殊现象：

Impossible WHERE noticed after reading const tables
这是一种优化器产生的提示，表示查询条件在当前上下文中恒不成立。例如使用唯一索引查询不存在的数据时，优化器可能在读取少量数据后即可断定结果为空，避免后续无效处理。但这可能导致额外的 I/O 消耗，在高并发场景下需谨慎评估唯一索引的使用策略。

总结而言，优化 SQL 时：

1. 优先确保 type 达到 ref 或 eq_ref，尽量避免 ALL。
2. 检查 Extra 是否包含 Using filesort 或 Using temporary，若有，考虑为排序或分组字段添加联合索引。
3. 尽量使用覆盖索引（Using index），避免不必要的回表操作。

以上就是 MySQL EXPLAIN 命令中 Type、Key 和 Extra 字段的详细内容，更多关于 MySQL 索引优化与慢查询排查的资料请关注本站其它相关文章！