MySQL执行计划是优化器实际生成的即将执行的查询步骤快照，而非理论模型；EXPLAIN是查看它的唯一标准入口，通过在SELECT等语句前添加即可获取，其type、rows、Extra等字段共同揭示性能瓶颈。
MySQL执行计划不是“理论模型”，而是优化器实际生成的、即将执行的查询步骤快照——它不预测，它展示数据库此刻打算怎么干。
EXPLAIN 是查看执行计划的唯一标准入口
在任意 SELECT、UPDATE、DELETE 或 INSERT 语句前加 EXPLAIN，就能触发 MySQL 返回执行计划而非真实结果。注意：EXPLAIN 不会真正执行语句（除极少数含子查询的场景外），但会解析、估算、规划全过程。
-
EXPLAIN SELECT * FROM users WHERE status = 1;最常用，直接看单表查询路径 -
EXPLAIN FORMAT=JSON SELECT ...输出结构化 JSON，适合程序解析或复杂 JOIN 嵌套分析 -
EXPLAIN FORMAT=TREE SELECT ...（MySQL 8.0.16+）以树形展示执行顺序，比传统表格更直观 - 不要用
DESCRIBE或DESC查执行计划——它们只适用于表结构，和EXPLAIN完全无关
type 字段决定查询效率天花板
type 是执行计划里最敏感的性能信号，它告诉你 MySQL 怎么定位数据行。值越靠前，效率越高：
-
const：主键或唯一索引等值查询，命中即止，最快 -
ref：非唯一索引等值匹配，比如WHERE category_id = ?，有索引但可能返回多行 -
range：范围扫描，如WHERE created_at BETWEEN '2026-01-01' AND '2026-06-30'，合理使用索引 -
index：全索引扫描，比全表略好，但仍是低效路径 -
ALL：全表扫描，rows 数一过万就要警觉——说明WHERE条件没走索引，或索引设计不合理
特别注意：type 为 ALL 时，key 列几乎总是 NULL；但反过来，key 非 NULL 也不代表高效——得看 type 是否落到 range 或更好级别。
rows 和 Extra 是性能瓶颈的显性证据
rows 是优化器估算的扫描行数，不是实际返回行数。数值越大，I/O 和 CPU 开销越不可控：
- 若
rows明显大于实际结果集（比如查 10 行却扫 50 万行），大概率是索引未覆盖WHERE或JOIN条件 -
Extra里出现Using filesort：ORDER BY 没走索引，强制内存/磁盘排序，大数据量下极易拖慢 -
Extra里出现Using temporary：GROUP BY 或 DISTINCT 触发临时表，尤其当tmp_table_size不足时会写磁盘 -
Extra同时出现两者（Using filesort+Using temporary），往往是排序 + 分组叠加导致，优先考虑复合索引覆盖
别轻信 rows 的绝对值——它是基于统计信息估算的，如果表刚大批量插入或删除后没 ANALYZE TABLE，估算可能严重失真。
真正难的是把 EXPLAIN 输出和业务 SQL 对齐：同一个字段，在 WHERE 里被函数包裹（如 YEAR(create_time) = 2026）就废掉索引；JOIN 顺序错位会让 type 从 ref 退化成 ALL；而 possible_keys 有多个却只用其中一个，往往意味着复合索引设计没对齐查询模式。
