直接看type、key、rows和Extra四列可快速判断查询效率：type需避免ALL/index，key与key_len验证索引使用，rows与filtered评估扫描与过滤效果，Extra中Using filesort或temporary需优化。
直接看 type、key、rows 和 Extra 这四列，就能快速判断查询是否高效。其他字段辅助定位执行逻辑，但核心瓶颈往往藏在这几处。
重点看 type：访问类型决定效率上限
type 表示 MySQL 怎么找数据，顺序从优到劣是：
system ≈ const > eq_ref > ref > range > index > ALL。
实际中重点关注是否掉到 index 或 ALL（全表扫描），这通常意味着缺索引或索引没用上。
- const：命中主键或唯一索引的等值查询，极快（比如
WHERE id = 123） - ref：用了非唯一索引，但可能返回多行（比如
WHERE status = 'active'，status 有普通索引） - range：走了索引范围扫描（如
WHERE created_at > '2025-01-01'），可接受，但范围越大越慢 - ALL：没走索引，逐行扫描整张表——要优先优化
确认 key 和 key_len：索引到底用没用、用对没用
key 显示实际生效的索引名；key_len 表示用了该索引的前多少字节。两者结合能验证索引使用是否充分。
- key 为 NULL：完全没走索引，查原因（字段没建索引？隐式类型转换？函数包裹字段？）
- key 有值但 key_len 很小：可能只用到了联合索引的最左前缀，右边字段未生效（例如索引是
(a,b,c)，但只查了WHERE a = 1，则 key_len 只含 a 的长度） - key_len 精确匹配预期：说明联合索引被完整利用（如
WHERE a = 1 AND b = 2 AND c > 3）
关注 rows 和 filtered：预估扫描量与过滤效果
rows 是 MySQL 预估要检查的行数，不是返回行数；filtered 是这一层条件过滤后剩余比例（百分比）。两者相乘约等于实际参与下一级连接或返回的行数。
- rows 值远大于实际结果集：说明 WHERE 条件区分度低，或索引选择性差
- filtered 接近 100%：条件基本没过滤，可能是无用 WHERE，也可能是索引没覆盖筛选字段
- rows 小但 filtered 很低：说明虽然扫描少，但过滤后只剩很少数据，可能需要加索引提升过滤效率
留意 Extra 中的关键提示
Extra 是执行过程中的补充行为，几个高频信号需立刻响应：
- Using filesort：需要额外排序，没走索引排序。解决办法是让 ORDER BY 字段包含在索引中，且顺序匹配
- Using temporary：创建临时表，常见于 GROUP BY、DISTINCT 或复杂子查询。尽量避免，可通过调整索引或重写查询减少
- Using index：好消息！表示覆盖索引，只查索引不回表，性能高
- Using where：正常现象，说明 WHERE 条件在存储引擎层之后做过滤（注意和 “Using index condition” 区分，后者是索引条件下推，更优）
