explain执行计划

要死磕的只有 4 个指标：type、key、rows 和 Extra。

 

指标一：type（访问类型）—— 最重要的性能指标

它表示 MySQL 如何查找数据行，性能从优到劣排序如下。你的优化目标，至少是要达到 range 级别，最好稳定在 ref 或 const。

级别（从优到劣）	含义	你的应对策略
system / const	神仙级别。命中主键或唯一索引，最多返回 1 条。	完美，无需优化。
eq_ref	极优。多表 JOIN 时，被驱动表使用主键或唯一索引关联。	完美，这是 JOIN 的最佳状态。
ref	优秀。命中普通索引（非唯一），返回匹配的多个值。	优秀，符合预期。
range	及格。使用了索引进行范围查询（如 >、IN、BETWEEN）。	必须达到的最低标准。
index	较差。扫描了整个索引树（比全表快一点，但代价依然很高）。	危险信号，说明没有过滤条件，或索引设计不合理。
ALL	极差。全表扫描（走磁盘读聚簇索引）。	严重性能杀手，必须立即添加索引优化。

 

指标二：key（实际使用的索引）—— 验证你的索引是否生效

• 看什么：查看 key 列是否是你预期的那个索引。

• 特别注意：要对比 possible_keys（优化器候选索引）和 key（最终选用的索引）。

• 如果 key 为 NULL：意味着没走索引（大概率 type 是 ALL），需要强制加索引或改写 SQL

指标三：rows（预估扫描行数）—— 评估 IO 负担

• 看什么：优化器预估需要读取的行数（不是最终返回的行数）。

• 核心原则：这个数字越小越好。如果 rows 达到几十万甚至上百万，即使 type 显示走了索引，也说明索引区分度太低，SQL 依然会很慢。

指标四：Extra（额外信息）—— 藏着性能陷阱的细节

这一列包含极其重要的警示信息，你需要像扫雷一样紧盯以下关键词：

 

Extra 中的关键字	严重程度	含义与后果	对策
Using filesort	🔴 致命	MySQL 需在内存或磁盘上额外排序（不是因为索引排序）。数据量大时极慢。	对 ORDER BY 字段建立合适的索引。
Using temporary	🔴 致命	使用了临时表（常见于 GROUP BY、DISTINCT、大表 JOIN）。比 filesort 还可怕。	优化分组逻辑，或为分组字段加索引。
Using index	🟢 福音	覆盖索引。查询所需的字段全在索引树中，不需要回表查主表。	这是最高效的状态，保持现状。
Using index condition	🟡 正常	使用了索引下推（ICP），优化器在引擎层过滤数据。	这是 MySQL 5.6 后的默认优化，正常。
Using where	🟡 正常	从存储引擎层返回数据后，Server 层再过滤。	如果同时没走索引，就是灾难；如果走了索引，正常。