MySQL中type=ALL或index表示未有效使用索引，尤其是JOIN右表出现ALL时需立即补索引；健康状态应为eq_ref、ref或range；key为空且possible_keys有值常因类型不一致或隐式转换导致。

type 字段：一眼判断是否在全表扫描

看到 ALL 或 index 就该立刻停住——这代表没走索引，或只扫了整个索引。尤其是 JOIN 右表出现 ALL，基本等于每次匹配都要遍历全表，数据量一过十万，查询就明显卡顿。

真正健康的信号是 eq_ref（主键/唯一索引等值查找）、ref（普通索引查找）或 range（范围扫描）。如果左表是 ref，右表却是 ALL，问题一定出在右表的 JOIN 字段没索引。

• MySQL 中 type=ALL 出现在右表 → 补 CREATE INDEX 到右表 ON 字段
• PostgreSQL / SQL Server 里看到 Seq Scan → 不是“可能慢”，是“一定慢”，必须干预
• type=index 表示走了索引但扫了全索引，和全表扫描性能接近，也得优化

key 和 possible_keys：索引到底用没用上

key 是优化器最终选中的索引，possible_keys 是它考虑过的候选。两者都为 NULL，说明所有索引都被跳过了；key 有值但 possible_keys 为空，可能是统计信息过期或隐式转换拦住了索引下推。

常见掉坑场景：

• JOIN 字段类型不一致：比如左表 user_id INT，右表 user_id VARCHAR(32) → 执行计划里会出现 Convert 或 Compute Scalar 节点
• ON 条件写了函数：ON UPPER(a.email) = UPPER(b.email) → 索引直接失效
• 复合索引顺序错位：ON t1.a = t2.x WHERE t2.status = 'done'，却建了 (status, x) 而不是 (x, status)

rows 和 filtered：预估 vs 实际，暴露过滤效率

rows 是优化器预估要检查的行数，filtered 是这之中被条件筛掉的比例。如果 rows 是 100 万但最终只返回 10 行，filtered 却只有 1%，说明 WHERE 或 ON 没走索引，靠的是扫描后硬过滤。

更为危险的情况是，rows远远超出了实际表的行数，这往往意味着统计信息不准确，或者优化器错误地判断了连接顺序。在这种情况下，EXPLAIN ANALYZE（PostgreSQL）或者EXPLAIN FORMAT=JSON（MySQL 8.0+）比单纯的EXPLAIN更为可靠，因为它会真实地执行并反馈实际扫描的行数。

• MySQL 用 ANALYZE TABLE 更新统计信息，别依赖自动更新
• PostgreSQL 用 VACUUM ANALYZE，尤其在大批量写入后
• SQL Server 查 DBCC SHOW_STATISTICS 确认 Rows Sampled 不是 0

Extra 列：藏着最具体的性能线索

数据库通过Extra里的短语，向我们传达“苦衷”呢，它可不是简单的备注。比如，Using join buffer意味着内存不足，无法执行NLJ（Nested Loop Join，嵌套循环连接），只能退而求其次，采用BNL（Block Nested Loop，块嵌套循环）；Using temporary和Using filesort这俩，在GROUP BY或ORDER BY操作中，如果索引未被完全覆盖，就容易出现；而Using where; Using index才是“理想国”——只需读取索引，无需回表查询，也不用进行过滤操作。

特别注意两个高危组合：

• Using temporary; Using filesort + 大表 JOIN → 很可能 SELECT * 或字段没覆盖索引
• Using join buffer + 高 rows → 内存不足触发块嵌套循环，IO 压力陡增

这些不是调优终点，而是定位起点：先让 type 正常，再压 rows，最后清理 Extra 里的警告词。中间任何一环断掉，后面优化都是隔靴搔痒。

《夸克》非常好用的免费AI浏览器

下载APP查看