EXPLAIN执行计划深度解析：从type到Extra全掌握

执行计划深度解析：从 type 到 Extra，全面掌握 EXPLAIN 的 SQL 调优价值

你是否经常使用 EXPLAIN 来查看 SQL 的执行计划，却未必完全理解每个字段的真正含义？type 到底有几种取值？Extra 中的 Using index、Using where、Using temporary、Using filesort 分别代表什么？key_len 如何计算？filtered 又有什么实际作用？今天我们就来完整解析 EXPLAIN 的输出，帮你彻底掌握 MySQL 查询优化技巧。

简单来说，type 代表 MySQL 查找行的效率：最优的是通过主键或唯一索引直接定位（const），最差的是全表扫描（ALL）。possible_keys 表示可能用到的索引，key 表示实际选用的索引。rows 是预计扫描的行数。filtered 显示存储引擎返回的行中满足后续 WHERE 条件的百分比。Extra 则提供额外操作信息，例如 Using where 表示需要回表过滤，Using temporary 表明使用了临时表。

一、EXPLAIN 输出列完整解读：MySQL 执行计划分析基础

执行 EXPLAIN SELECT ... 语句后，会得到一张包含各字段含义的表：

虽然表格字段较多，但日常 SQL 优化重点关注 type、key、rows、Extra，以及涉及联合索引的 key_len。

二、type 详解：MySQL 连接类型与性能优化

type 字段表示 MySQL 如何查找表中的行，性能从最优到最差排列如下：

优化目标非常明确：至少达到 range 级别，尽量提升到 ref 或 const。

案例：

-- type = ALL 表示全表扫描，性能较差
EXPLAIN SELECT * FROM orders WHERE amount > 100;
-- 添加索引后 type 变为 range
ALTER TABLE orders ADD INDEX idx_amount(amount);

三、Extra 详解：MySQL 优化器隐藏的执行信息

Extra 字段包含了查询执行过程中的额外操作信息，是定位 SQL 性能瓶颈的关键线索：

注意：Using filesort 并非真的使用文件，而是表示无法利用索引排序，需要在内存或磁盘中进行额外排序。当排序结果集较大时，性能会显著下降。

案例：

-- Using filesort 表示排序需额外处理
EXPLAIN SELECT * FROM orders ORDER BY create_time;
-- 加索引后 Using filesort 消失
ALTER TABLE orders ADD INDEX idx_create_time(create_time);

四、组合索引与 key_len 实战：索引长度计算与最左前缀原则

key_len 表示 MySQL 在执行索引操作时实际使用的字节长度，可用于判断联合索引中具体使用了多少列。

计算规则：

INT 长度为 4 字节，BIGINT 为 8 字节，DATE 为 3 字节，TIMESTAMP 为 4 字节，CHAR(n) 的长度为 n×字符集字节数（utf8mb4 下每个字符 4 字节），VARCHAR(n) 为 n×4 + 2 字节。若允许 NULL，则额外加 1 字节。

来看一个具体例子：联合索引 (user_id, log_date, type)，其中 user_id INT NOT NULL (4 字节)，log_date DATE NOT NULL (3 字节)，type TINYINT (1 字节)。执行 WHERE user_id=1 AND log_date='2026-06-01' 时，key_len=4+3=7，表明使用了前两列。

这里的关键是联合索引使用原则：最左前缀，且中间的列不能跳过。如果跳过了某列，后面的列将不会被使用。

五、filtered 的作用：评估索引过滤效率

filtered 字段表示存储引擎返回的行中，满足后续 WHERE 条件的估算百分比。100% 意味着所有返回行都符合条件。若 filtered 值较小（例如 10%），说明索引过滤后仍有大量行需要进一步过滤，导致回表成本增加。

应用场景：在多表 JOIN 中，驱动表的 filtered 值直接影响被驱动表的读取次数，用于评估整体查询性能。

六、实战案例优化全过程：从 SQL 到索引设计

原始 SQL：

SELECT * FROM orders 
WHERE customer_id = 12345 
  AND status = 'PAID' 
  AND create_time > '2026-01-01'
ORDER BY create_time DESC
LIMIT 10;

原执行计划：type=ref，key=customer_id，rows≈1000，Extra="Using where; Using filesort"。

问题分析：

虽然使用了 customer_id 索引，但 status 和 create_time 的过滤条件需要在回表后执行。同时，由于 create_time 不在索引中，排序操作无法利用索引，导致 Using filesort。

优化方案： 建立联合索引 (customer_id, status, create_time)。

新执行计划：type=ref，key=联合索引，key_len=4+?，Extra=无 Using filesort（因为索引已排序）。

效果：查询耗时从 0.5 秒降至 0.02 秒。

七、总结与实用检查清单：快速定位 SQL 性能问题

分析 EXPLAIN 输出时，建议按以下顺序排查：

1. type： 检查是否出现 ALL 或 index，若有则需添加适当索引。
2. key： 若为 NULL，表示未使用索引，需优化查询条件或索引设计。
3. rows： 远大于预期时，检查索引选择性是否足够。
4. Extra： 出现 Using temporary 或 Using filesort 时，需优化排序或分组逻辑，或添加索引。
5. filtered： 低于 30% 时，应考虑创建覆盖更多过滤条件的索引。