关键词​EXPLAIN执行计划typeExtraSQL优化索引大家好我是小耶写功课只是为了我踩过的坑你们别再踩了你肯定用过EXPLAIN看 SQL 的执行计划但你有没有真正看全过type到底有几种取值Extra里的Using index、Using where、Using temporary、Using filesort分别什么意思key_len怎么算filtered有什么用今天我们就来把EXPLAIN的输出彻底讲透。​用“快递分拣系统”来类比理解执行计划​type相当于分拣效率最快的是“直接按门牌号送”const最慢的是“翻遍整个仓库”ALL。possible_keys 可能用的传送带key 实际选的传送带。rows 需要检查的包裹数量。filtered 初步分拣后还需要人工二次分拣的比例。Extra 额外操作标记如“用了传送带但还要人工挑拣”Using where、“需要临时堆货”Using temporary。一、EXPLAIN 输出列完整解读我们用EXPLAIN SELECT ...会得到一张表每个列的含义如下列名含义关键点idSELECT 的标识序号越大越先执行相同则从上到下select_type查询类型SIMPLE、PRIMARY、SUBQUERY、DERIVED、UNION 等table表名或别名可能是临时表名partitions匹配的分区分区表时有用type连接类型重要性能从好到差system const eq_ref ref range index ALLpossible_keys可能使用的索引列出候选索引key实际使用的索引如果 NULL 表示没用到索引key_len使用索引的长度字节判断联合索引用了多少列ref索引列与哪个值比较常量 const 或 列名rows预估需要扫描的行数越大越差filtered存储引擎返回的行中满足剩余条件的比例100% 最好Extra额外信息Using index、Using where、Using temporary、Using filesort 等二、type 详解性能的关键指标type 表示 MySQL 如何查找表中的行按性能从最优到最差排序type含义示例出现条件system系统表只有一行极少见系统表或 const 的特例const最多匹配一行用主键或唯一索引等值查询WHERE id 1主键或唯一索引且查询结果为常量eq_ref使用唯一索引进行关联每个关联只返回一行JOIN ... ON t1.id t2.id且 t2.id 是主键被驱动表使用主键或唯一索引连接ref使用非唯一索引或前缀索引进行等值匹配WHERE name abcname 有普通索引索引列不是唯一或可为 NULLrange索引范围扫描WHERE id BETWEEN 1 AND 100或IN、、索引列上的范围条件index全索引扫描索引覆盖但没过滤条件遍历整个索引树ALL全表扫描最差无索引或优化器认为全表更快大表且无有效索引​优化目标​至少达到range级别争取达到ref或const。​案例​-- type ALL 很差 EXPLAIN SELECT * FROM orders WHERE amount 100; -- 添加索引后 type 变为 range ALTER TABLE orders ADD INDEX idx_amount(amount);三、Extra 详解优化器还做了什么Extra 列包含关于查询执行的额外信息很多关键优化线索都在这里Extra 信息含义优劣优化方向Using index使用了覆盖索引不回表✅ 好继续保持Using where存储引擎返回后在 Server 层过滤 普通尝试将过滤条件移到索引中Using temporary使用了临时表通常用于 GROUP BY 或 DISTINCT⚠️ 差优化 GROUP BY/ORDER BY 或加索引Using filesort需要额外排序不能利用索引排序⚠️ 差对 ORDER BY 列加索引Using index condition使用索引下推ICP✅ 好MySQL 5.6 自动优化Using join buffer连接使用了 BufferBlock Nested Loop 普通加索引避免 BufferImpossible WHEREWHERE 条件永远为假无需优化检查 SQL 逻辑No tables used没有 FROM 或 FROM DUAL--​注意​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 在索引中实际使用的字节数。通过它可判断联合索引使用了多少列。​计算规则​列长度INT4, BIGINT8, DATE3, TIMESTAMP4, CHAR(n)n×字符集字节数utf8mb44VARCHAR(n)n×42。允许 NULL 额外 1。​示例​索引(user_id, log_date, type)user_id INT NOT NULL (4)log_date DATE NOT NULL (3)type TINYINT (1)。查询WHERE user_id1 AND log_date2026-06-01则key_len437说明用到了前两列。​联合索引使用原则​最左前缀且中间的列不能跳过。如果跳过了某列后面的列不会被使用。五、filtered 的作用filtered表示存储引擎返回的行中满足剩余 WHERE 条件的比例估算。100% 表示所有返回行都满足条件。如果 filtered 很小如 10%说明索引过滤后还要过滤掉 90% 的行回表成本高。​用法​在 JOIN 中驱动表的 filtered 值直接影响被驱动表的读取次数。六、实战案例优化全过程​原始 SQL​SELECT * FROM orders WHERE customer_id 12345 AND status PAID AND create_time 2026-01-01 ORDER BY create_time DESC LIMIT 10;​原执行计划​typerefkeycustomer_idrows1000Extra“Using where; Using filesort”。​问题分析​用了 customer_id 索引但 status 和 create_time 过滤在回表后执行。filesort 因为 create_time 没在索引中用于排序。​优化方案​建立联合索引(customer_id, status, create_time)。​新执行计划​typerefkey联合索引key_len4?3Extra无 filesort因为索引已排序。​效果​查询从 0.5 秒降到 0.02 秒。七、总结与实用检查清单阅读EXPLAIN时按以下顺序检查​type​是否出现了 ALL 或 index如果是考虑加索引。​key​是否为 NULL是则索引没用上。​rows​是否远大于预期检查索引选择性。​Extra​是否出现 Using temporary 或 Using filesort优化排序和分组。​filtered​是否低于 30%检查索引是否能覆盖更多过滤条件。小耶在手SQL 不愁还有什么想了解的欢迎留言小耶一定知无不言言无不尽……我们下次见~参考文献MySQL官方文档《EXPLAIN Output Format》《高性能MySQL》第4版第9章查询优化