SQL优化之Explain关键字详解

type 字段：访问类型（性能核心指标）

• 优化目标：避免 ALL（全表扫描），尽量达到 ref 或 range。
• 性能排序：
  system > const > eq_ref > ref > range > index > ALL 
  • system：表仅一行数据（如系统表）。
  • const：通过主键或唯一索引直接定位单行（如 WHERE id = 1）。
  • eq_ref：多表 JOIN 时，被驱动表的主键/唯一索引被完全使用（每行仅匹配一次）。
  • ref：非唯一索引的等值查询（可能返回多行）。
  • range：索引范围扫描（如 BETWEEN、IN）。
  • index：全索引扫描（遍历索引树，但未过滤数据）。
  • ALL：全表扫描，性能最差，需通过索引优化避免 。

---

2. key 与 possible_keys：索引使用情况

• possible_keys：可能使用的索引（若为空，说明无合适索引）。
• key：实际使用的索引。若为 NULL，需检查 WHERE 条件或索引设计 。
• 优化建议：
  • 联合索引需遵循 最左前缀原则（如索引 (a, b, c) 仅支持 a、a AND b 等条件）。
  • 使用 覆盖索引（索引包含查询所需字段），使 Extra 列显示 Using index，减少回表操作 。

---

3. rows：预估扫描行数

• 表示优化器估算需检查的行数，数值越小越好。
• 若实际行数与 rows 差异大，可能因统计信息不准确，可通过 ANALYZE TABLE 更新 。

---

4. Extra：额外信息（关键优化提示）

• Using index：使用覆盖索引，无需回表。
• Using where：WHERE 条件过滤了部分数据。
• Using filesort：需额外排序（如未使用索引排序），可通过索引优化避免。
• Using temporary：使用临时表（如 GROUP BY 无索引），需优化查询或索引 。

---

5. id 与 select_type：查询结构与执行顺序

• id：
  • 相同 id 按顺序执行；不同 id 时，值越大优先级越高（如子查询 id 递增）。
• select_type：
  • SIMPLE：简单查询（无子查询或 UNION）。
  • PRIMARY：外层查询。
  • DERIVED：FROM 子句中的子查询，生成临时表。
  • SUBQUERY：WHERE 中的子查询。
  • 避免 DEPENDENT SUBQUERY（子查询依赖外层结果），因其效率低下 。

---

6. key_len：索引使用长度

• 表示索引中使用的字节数，可判断是否充分利用组合索引。
  • 例如，varchar(20) 的 utf8 字段，若 key_len 为 63（3*20 + 2），说明该字段被完整使用 。