MySQL优化实战（二：explain参数详解）

分析一个“慢查询”的 EXPLAIN 结果

我们先写一个可能变慢的 SQL的执行计划：

EXPLAINSELECTr.nameAScity_name,st.nameAStype_name,si.nameASitem_name,s.priceAScurrent_priceFROMserve sJOINregion rONs.region_id=r.idJOINserve_item siONs.serve_item_id=si.idJOINserve_type stONsi.serve_type_id=st.idWHEREr.name='北京市'ANDsi.active_status=2ANDs.sale_status=1;

得到如下结果：

一、EXPLAIN 各列详解

id

• 含义：查询中每个 SELECT 的唯一标识符。
• 解读：
  • id=1是主查询（最外层）
  • 如果有子查询，会是id=2、id=3等
• 本例中只有一个查询，所以全是1

select_type

• 含义：查询类型。
• 常见值：
  • SIMPLE：简单查询（无子查询、UNION）
  • PRIMARY：主查询（外层查询）
  • SUBQUERY：子查询
  • DEPENDENT SUBQUERY：依赖外部查询的子查询
• 本例中都是SIMPLE，说明是单条查询

table

• 含义：当前正在访问的表名。
• 按顺序是：si→s→st→r

partitions

• 含义：如果表分区，显示使用的分区。
• 当前为NULL，说明未使用分区表。

type—— 决定性能好坏

分析我们的实际情况：

possible_keys

• 含义：数据库认为可以用于该表的索引列表。
• 例如：si的possible_keys是PRIMARY, serve_type_id
  → 说明数据库知道id和serve_type_id可以用来加速查询。

但注意：只是“可能”用，不保证真的用！

key

• 含义：实际使用的索引。
• 关键点：
  • key = NULL→ 没用任何索引（全表扫描）
  • key = PRIMARY→ 用了主键索引
  • key = serve_item_id→ 用了外键索引

分析：

key_len

• 含义：索引使用的字节数。

你可以通过它判断是否使用了完整索引。

ref

• 含义：表示与索引比较的值或列。
• 例如：
• jzo2o-foundations.si.id→ 用si.id去匹配s.serve_item_id
• jzo2o-foundations.si.serve_type_id→ 用si.serve_type_id去匹配st.id

它告诉你：“我用哪个字段去关联？”

rows

• 含义：MySQL 预估需要扫描的行数。
• 数字越小越好！
• 例如：
  • rows = 6→ 扫描 6 条记录
  • rows = 100000→ 扫描 10万条 → 很慢！

这个数字是估算值，受统计信息影响。

filtered

• 含义：在使用索引后，还需要过滤多少百分比的数据。
• 范围：0~100
• 例如：filtered = 16.67→ 索引找到的行中，只有 16.67% 符合条件

如果这个值很低（<10），说明索引没帮上忙，还是得大量过滤。

Extra

• 含义：额外信息.
• 常见值：
  • Using where→ 查询中有 WHERE 条件，且不能完全由索引覆盖
  • Using index→覆盖索引！只用索引就能返回结果，不用回表
  • Using filesort→ 需要排序，可能很慢
  • Using temporary→ 创建临时表，通常是因为 GROUP BY 或 DISTINCT

分析你的Extra：

si的Using where+ALL→双重打击：先全表扫，再过滤！

总结：

1.第一个表si：全表扫描（ALL）

• 看到type: ALL，说明 MySQL 是从头到尾把si表的所有数据都扫了一遍。
• 虽然它只查了 6 行，但“全表扫描”是个危险信号，尤其是当数据量变大时会很慢。
• 为什么？因为虽然有PRIMARY和类型id可能的索引，但最终没用上。

2.第二个表s：用了索引（ref），但效率一般

• type: ref是个好现象，说明用了索引查找。
• 它用了服务id和区域id的组合索引，这是对的。
• 但是filtered: 10很低，意味着虽然找到了一些行，但大部分都被后续条件过滤掉了。

3.第三个表st：很好，直接主键定位（eq_ref）

• type: eq_ref，说明是通过主键精确匹配的，非常高效。
• 只查了 1 行，也没问题。
• 结论：这部分已经很完美了，不用改。

4.第四个表r：也用了主键（eq_ref），但有点小问题

• 同样是eq_ref，靠主键查的，看起来没问题。
• 但filtered: 8.33很低，说明虽然查到了 1 行，但这个行还要被WHERE条件再筛一遍，可能很多不满足。