type=ALL不等于“没索引”，而是优化器放弃所有可用索引进行全表扫描；需结合possible_keys（有值则候选索引存在）、key（为NULL说明未选用）、key_len（判断联合索引使用程度）及Extra字段综合诊断。
EXPLAIN 返回的 type=ALL 真的等于“没索引”吗？
不一定。看到 type=ALL 第一反应是“加索引”，但得先确认是不是真没可用索引：possible_keys 为 NULL 才说明优化器根本没候选索引；如果 possible_keys 有值而 key 是 NULL，说明优化器评估后认为走索引比全表扫描还慢——常见于小表、低区分度字段（如 status 只有 0/1）、或 WHERE 条件写法导致索引失效（比如对索引列用函数）。此时强行建索引反而浪费写入开销。
key_len 比预期小，说明联合索引没被完整利用
比如你建了联合索引 idx_user_id_status_created_at，但 EXPLAIN 显示 key_len=5（只用了 user_id 的 INT 长度），而没算上 status 和 created_at，那基本可以断定：WHERE 中缺失了最左前缀的连续等值条件。例如只写了 WHERE user_id = 123 AND created_at > '2025-01-01'，中间跳过了 status，右边的 created_at 就无法命中索引。必须保证从左到右的字段是“等值链”，范围查询只能放在最后一位。
Extra 出现 Using filesort 或 Using temporary 怎么办？
这两个不是警告，是明确的性能缺陷信号：Using filesort 表示排序没走索引，Using temporary 表示 GROUP BY / DISTINCT / 多表 JOIN 时不得不建临时表。它们常一起出现，比如 ORDER BY create_time DESC 但索引里 create_time 不在最右位，或没和 WHERE 字段构成连续索引路径。解决方式不是“优化 SQL”，而是补索引：让 ORDER BY 字段紧接在 WHERE 等值字段之后，且方向一致（都 ASC 或都 DESC）；GROUP BY 同理，字段顺序必须和索引定义完全匹配。
rows 和 filtered 联合看，才能判断索引是否真有效
rows=100000 看着吓人，但如果 filtered=10.00（即 10%），说明 MySQL 预估从索引里捞出 10 万行，其中只有 1 万行满足 WHERE 其他条件——这大概率是索引设计太窄，或者条件里混入了无法下推的表达式（比如 JSON_EXTRACT、隐式类型转换）。更隐蔽的是 rows 极小但响应仍慢：可能是回表代价高（SELECT * + 二级索引），也可能是统计信息过期，这时要跑 ANALYZE TABLE 更新行数估算，而不是急着改 SQL。
