执行计划与EXPLAIN
执行计划是优化器选择访问路径后的结果。EXPLAIN 能告诉我们表访问顺序、索引选择、扫描行数、连接方式、排序和临时表情况，是 SQL 优化的第一证据。
# 1. 学习定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 优化工具 |
| 核心目标 | 先会用，再理解机制，最后能做工程取舍和故障分析 |
| 学习方法 | 带着业务场景看命令、SQL、数据结构、日志和运行时指标 |
# 2. 核心地图
执行计划与EXPLAIN
├─ id
├─ select_type
├─ table
├─ type
├─ possible_keys
├─ key
├─ rows
├─ filtered
├─ Extra
└─ EXPLAIN ANALYZE
# 3. 小章节深度讲解
下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。
# 3.1. id
# 是什么
EXPLAIN 的 id 表示查询块编号。编号相同通常表示同一层查询或同一组执行单元，编号不同则常见于子查询、派生表、UNION 等复杂结构。
# 开发人员怎么用
开发人员可以通过 id 看 SQL 是否被拆成多个查询块，从而判断复杂 SQL 是否需要重写。子查询层级过多时，可考虑 JOIN、临时结果或业务拆分。
# 运维人员怎么看
运维人员分析慢 SQL 时，id 能帮助定位到底是哪一层查询产生大扫描或临时表。不要只看最外层 SELECT，真正慢的可能是派生表或子查询。
# 常见风险
常见风险是看到最外层条件有索引就以为安全，忽略内层子查询或派生表已经扫描了大量数据。
# 3.2. select_type
# 是什么
select_type 表示查询块类型，例如 SIMPLE、PRIMARY、SUBQUERY、DERIVED、UNION。它能说明优化器把 SQL 拆成了怎样的逻辑单元。
# 开发人员怎么用
开发人员要重点关注 DERIVED、DEPENDENT SUBQUERY 等类型。它们可能表示派生表物化或相关子查询反复执行，常常是复杂 SQL 性能问题的入口。
# 运维人员怎么看
运维人员看到慢 SQL 中出现复杂 select_type，要结合 rows、Extra 和实际耗时判断是否存在临时表、重复执行和无法下推过滤的问题。
# 常见风险
常见风险是为了可读性堆叠多层子查询，结果优化器无法有效合并，生产数据一大就出现指数级放大。
# 3.3. table
# 是什么
table 列表示当前执行步骤访问的表、派生表或临时结果。它不一定是物理表名，也可能是
# 开发人员怎么用
开发人员要用 table 列确认驱动表和被驱动表是否符合预期。多表 JOIN 中，先访问哪张表会直接影响中间结果大小。
# 运维人员怎么看
运维人员通过 table 列能定位热点表、临时派生表和大扫描来源。慢 SQL 治理时应把 table、rows、key 一起看。
# 常见风险
常见风险是只优化最终业务表，忽略派生表已经在前面生成了巨大中间结果。
# 3.4. type
# 是什么
type 是访问方式，表示 MySQL 如何从表中取数据。常见值从 const、eq_ref、ref、range、index 到 ALL，通常越靠后扫描范围越大。
# 开发人员怎么用
开发人员要重点避免大表 ALL 扫描，也要理解 range 后联合索引后续字段的利用边界。type 好看不代表一定快，返回行数和回表同样重要。
# 运维人员怎么看
运维人员看到 type 退化，要检查统计信息、参数值、隐式转换、函数计算和索引可用性。执行计划漂移经常先体现在 type 和 key 变化上。
# 常见风险
常见风险是机械追求 type=const/ref，而忽略业务本身需要扫描大量范围。优化要看总成本，而不是单列指标。
# 3.5. possible_keys
# 是什么
possible_keys 是优化器认为理论上可能使用的索引集合。它说明哪些索引与查询条件有关，但不代表最终一定会选用。
# 开发人员怎么用
开发人员可以用它判断 SQL 条件是否至少能匹配到候选索引。如果这里为空，通常要检查字段类型、函数计算、隐式转换或条件写法。
# 运维人员怎么看
运维人员要把 possible_keys 和 key 对比。如果候选很多但最终选择异常，可能是统计信息不准、数据倾斜或成本估算偏差。
# 常见风险
常见风险是看到 possible_keys 里有目标索引就放心，实际 key 没选它，SQL 仍然慢。候选索引不是执行索引。
# 3.6. key
# 是什么
key 是优化器最终选择的索引。它是执行计划中最关键的列之一，但仍要结合 key_len、rows、filtered 和 Extra 判断效果。
# 开发人员怎么用
开发人员要验证 key 是否符合设计目的：联合索引是否用了正确前缀，排序是否能复用索引顺序，是否覆盖所需字段。
# 运维人员怎么看
运维人员要关注 key 的计划稳定性。同一 SQL 在不同参数、不同时间选择不同索引，可能导致偶发慢查询。
# 常见风险
常见风险是强制索引后短期变快，长期随着数据分布变化变慢。强制索引必须有退出策略。
# 3.7. rows
# 是什么
rows 是优化器估算需要扫描的行数，不是实际返回行数。它基于统计信息和成本模型，可能和真实执行有明显偏差。
# 开发人员怎么用
开发人员要把 rows 当作风险信号。rows 很大说明访问路径可能过宽，即使最终 LIMIT 返回很少，也可能已经扫描或排序了很多数据。
# 运维人员怎么看
运维人员要用 EXPLAIN ANALYZE 或运行指标校验 rows 准确性。估算偏差大时，可能需要更新统计信息、检查直方图或处理数据倾斜。
# 常见风险
常见风险是只看查询返回 10 行，忽略 rows 估算几十万行。用户看到的是结果，数据库付出的是扫描成本。
# 3.8. filtered
# 是什么
filtered 表示经过表条件过滤后预计剩余行的百分比。它与 rows 相乘，可以粗略估算传递给下一步的行数。
# 开发人员怎么用
开发人员用 filtered 判断条件是否足够有选择性。如果 rows 很大且 filtered 很低，说明大量数据被读出来后才过滤，索引可能没有贴近条件。
# 运维人员怎么看
运维人员可用 filtered 识别连接顺序问题。上游步骤过滤率低会把大量中间结果传给后续 JOIN、排序和聚合。
# 常见风险
常见风险是只看 key 使用了索引，却忽略 filtered 很低，说明索引没有真正减少足够多的数据。
# 3.9. Extra
# 是什么
Extra 展示额外执行信息，如 Using where、Using index、Using temporary、Using filesort、Using index condition。它能暴露排序、临时表、覆盖索引和下推情况。
# 开发人员怎么用
开发人员看到 Using temporary 或 Using filesort 要判断数据量和排序字段是否可控，不要机械恐慌；看到 Using index 则要确认是否真的覆盖了查询字段。
# 运维人员怎么看
运维人员要把 Extra 与磁盘临时表、sort merge passes、CPU、IO 指标结合。临时表和文件排序在高并发下会迅速放大资源消耗。
# 常见风险
常见风险是把 Extra 当成绝对好坏标签。小结果集 filesort 很正常，大结果集 Using temporary 才可能成为事故源。
# 3.10. EXPLAIN ANALYZE
# 是什么
EXPLAIN ANALYZE 会真实执行 SQL，并输出实际耗时、实际行数、循环次数等运行时信息。普通 EXPLAIN 更像优化器的“预估计划”，EXPLAIN ANALYZE 则能把预估和实际执行差距暴露出来。
# 开发人员怎么用
开发人员在优化复杂 SQL 时，可以先用普通 EXPLAIN 看计划，再用 EXPLAIN ANALYZE 验证真实执行。需要注意它会真正执行语句，分析写 SQL 时必须放在测试环境或可回滚事务中，不能随意对生产写语句执行。
# 运维人员怎么看
运维人员可以用它判断 rows 估算是否失真、某个算子是否循环过多、实际耗时集中在哪一步。它特别适合定位优化器误判、数据倾斜、统计信息不准和连接顺序异常。
# 常见风险
常见风险是在生产高峰对大 SQL 执行 EXPLAIN ANALYZE，导致查询被真实跑一遍，反而增加负载。使用前要确认语句类型、数据量、事务边界和业务影响。
# 3.11. 本篇学习实验
建议准备一个至少百万行级别的测试表，分别观察正常查询、缺失索引、错误索引、长事务、锁等待和慢查询日志。每次实验都记录 SQL、执行计划、耗时、扫描行数和 MySQL 状态变量变化。
开发侧实验重点是理解 SQL 与事务边界，运维侧实验重点是理解指标如何变化。真正掌握本篇内容，应该能从现象反推 SQL、索引、锁、日志或存储引擎问题。
# 4. 核心机制
type表示访问方式，从system/const到ALL通常成本逐步升高，但不能只看这一列。rows是估算扫描行数，依赖统计信息，可能与真实执行有差距。Extra中的Using filesort、Using temporary、Using index、Using where都需要结合上下文判断。EXPLAIN ANALYZE可以看到真实执行耗时和行数，更适合验证优化效果。
# 5. 工程实践
- 优化前保存原始 SQL、执行计划、耗时、扫描行数和样本参数。
- 先看驱动表是否合理，再看连接字段和索引是否匹配。
- 看到
ALL不一定立刻加索引，小表全表扫描可能更便宜。 - 优化后用真实参数和生产相近数据量复测。
# 6. 常见坑
- 只看是否使用索引，不看 rows 和 filtered。
- 看到
Using filesort就恐慌，实际小结果集排序成本可能很低。 - 用测试库少量数据判断生产执行计划。
- 忽略参数不同导致计划不同。
# 7. 专家视角
- 执行计划是优化沟通语言，可以让开发、DBA 和架构师基于同一证据讨论。
- 专家会把计划估算和真实执行对比，发现统计信息、数据倾斜和优化器误判。
- SQL 优化要形成实验记录，而不是凭感觉修改。
# 8. Tips 快问快答
Q：EXPLAIN 的 rows 是真实行数吗？
A：通常是估算值，真实情况要结合 EXPLAIN ANALYZE 或运行指标。
Q：Using filesort 一定很慢吗？
A：不一定，要看数据量、内存、排序字段和是否可用索引顺序。
Q：为什么测试库计划和生产不同？
A：数据量、分布、统计信息、参数和版本都可能不同。
# 9. 阶段小结
执行计划与EXPLAIN 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。