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，退化成 BNL；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 里的警告词。中间任何一环断掉，后面优化都是隔靴搔痒。
