SQL执行计划是数据库优化器生成的树状“操作蓝图”，描述数据读取、过滤、连接等步骤；需重点关注type、key、rows、Extra、filtered五字段及连表、排序、COUNT(*)三类慢场景。
SQL执行计划是数据库优化的核心工具，看懂它，等于拿到了查询性能的“诊断报告”。关键不是记住所有算子名称，而是理解每个环节在做什么、为什么慢、哪里能改。
执行计划到底是什么？
它是数据库优化器为执行某条SQL生成的“操作蓝图”——不是代码，也不是日志，而是一棵树状结构，描述数据从磁盘/内存中如何被读取、过滤、连接、排序、聚合，最终返回结果。MySQL用EXPLAIN，PostgreSQL用EXPLAIN ANALYZE，Oracle用EXPLAIN PLAN，本质一致。
必须盯住的5个核心字段
以MySQL的EXPLAIN输出为例（其他数据库逻辑相通）：
- type：连接类型，反映访问效率。从好到差大致是：const ≈ system > eq_ref > ref > range > index > ALL。出现red">ALL（全表扫描）或index（全索引扫描）要警惕，尤其数据量大时
- key：实际使用的索引名。为NULL？说明没走索引，可能因条件不匹配、索引失效、或优化器误判
- rows：优化器预估需要扫描的行数。不是实际行数，但和实际耗时强相关。若预估100行，实际扫描10万行，说明统计信息过期或选择率判断严重偏差
- Extra：补充信息，高频警告项包括：Using filesort（需额外排序，常因ORDER BY字段无索引或索引不覆盖）、Using temporary（建临时表，常见于GROUP BY+非索引字段、UNION、某些子查询）
- filtered（MySQL 5.7+）：表示该表条件过滤后剩余数据的百分比。值越低，说明WHERE条件越有效；若只有10%，但rows却很大，说明索引区分度差或条件写法有问题（如对字段加函数）
三个典型慢场景与执行计划线索
不必死记算法，抓住模式就能快速定位：
- 连表慢？看type和rows组合：比如t1驱动t2，t1.type=ref（合理），但t2.type=ALL且rows=50万——大概率t2缺少关联字段上的索引，或ON条件用了函数/类型隐式转换
- ORDER BY慢？盯Extra和key：出现Using filesort + key=NULL，说明排序字段完全没走索引；若key有值但Extra仍有Using filesort，可能是索引顺序不满足排序需求（如索引是(a,b)，ORDER BY b,a就不覆盖）
- COUNT(*)卡住？看是否走了索引扫描：InnoDB下，如果key显示PRIMARY或某个索引，且type=index，说明走了索引遍历（快）；若type=ALL，就是全表扫，尤其大表极慢。注意：没有WHERE时，优化器可能选最小索引而非主键
分析不是终点，验证才是关键
执行计划是“预测”，真实性能得靠实测：
- 用EXPLAIN ANALYZE（PG）或MySQL 8.0+的EXPLAIN FORMAT=TREE带实际执行时间、真正扫描行数，对比预估差异
- 加SQL_NO_CACHE（MySQL）或清缓存后再测，避免命中查询缓存干扰判断
- 修改后重看执行计划——索引加了，type是否从ALL变成range？rows是否从10万降到500？Extra是否消失？这些变化比“快了2秒”更有说服力
基本上就这些。执行计划不是密码本，而是一张动态的性能地图。看懂它，你就掌握了从“猜问题”到“定病因”的能力。不复杂，但容易忽略细节。
