执行计划分析需建立“查询意图→物理路径→性能瓶颈”闭环逻辑，核心是树形结构自底向上解读、盯住代价偏差、实测验证假设、回归SQL与模型根因。
SQL执行计划不是看懂几个名词就完事的，关键在于建立“从查询意图→物理执行路径→性能瓶颈”的闭环分析逻辑。真正能快速定位慢查的人，靠的不是死记Index Scan比Seq Scan快，而是能顺着执行树反推：数据库为什么选这条路？代价估算依据是什么？哪里在拖慢整体？
看清结构：执行计划不是平铺列表，而是一棵自底向上的执行树
PostgreSQL/Oracle/MySQL（8.0+）的执行计划本质是树形结构，最底层节点是数据来源（如表扫描、索引读取），逐层向上做连接、聚合、排序等操作，根节点是最终返回结果。阅读时必须从下往上、从内向外看：
- 先找叶子节点：哪些表被访问？用的是全表扫描（
Seq Scan）、索引扫描（Index Scan）、还是索引只读（Index Only Scan）？有没有出现意料之外的全扫？ - 再看中间节点：连接方式是
Nested Loop、Hash Join还是Merge Join？驱动表是谁？连接条件是否走索引？ - 最后看顶层节点：是否有
Sort？是否触发了临时文件（disk: XkB）？Limit是否下推到了扫描层？
盯住代价：估算值≠实际耗时，但偏差大就是信号灯
执行计划中的cost（如cost=100..2000）是优化器基于统计信息做的相对估算，单位无意义，但各节点间可横向比较。重点看三类偏差：
-
rows远小于actual rows：说明统计信息过期（
ANALYZE没跑或采样不足），优化器低估了数据量，可能误选嵌套循环或小内存排序； - actual time中某步耗时占比超70%：不用纠结其他节点，这就是瓶颈所在，优先检查该步骤涉及的索引、过滤条件、数据分布；
- Buffers中shared hit极低、read很高：说明缓存未生效，可能是查询太随机、数据集远超work_mem，或刚重启库还没预热。
验证假设：别信计划，要测行为
执行计划是优化器的“预测稿”，真实表现还得靠实测。三个低成本验证动作：
- 加
/*+ USE_INDEX(t1 idx_a_b) */（MySQL）或SET enable_hashjoin = off（PG）强制走某路径，对比EXPLAIN (ANALYZE, BUFFERS)的实际耗时； - 用
pg_stat_statements（PG）或performance_schema.events_statements_summary_by_digest（MySQL）查该SQL历史平均延迟和调用频次，判断是偶发抖动还是稳定慢； - 对疑似瓶颈字段，手动执行
SELECT COUNT(*) WHERE 条件，验证选择率是否真如优化器估算（比如WHERE status='done'实际占95%，但优化器按5%算，就会错选索引）。
回归业务：执行计划只是镜子，问题永远在SQL和模型里
所有执行计划异常，根因几乎都落在三处：
-
SQL写法不合理：隐式类型转换（
WHERE mobile = 13800138000导致索引失效）、OR连写未拆解、SELECT *拖垮网络和内存； -
索引设计不匹配访问模式：高频查询要
WHERE a= ? AND b > ? ORDER BY c，却只建了(a)单列索引，缺复合索引(a,b,c)； - 数据模型存在冗余或反范式缺陷：一张订单表硬塞了用户昵称、商品类目、店铺地址，每次JOIN都放大IO，不如拆成窄表+应用层组装。
基本上就这些。执行计划不是终点，是帮你把“这SQL怎么这么慢”转化成“哪一行数据没走索引”“哪个JOIN在写磁盘”“哪次排序爆了内存”的翻译器。练熟了，看一眼EXPLAIN ANALYZE输出，心里就有谱。
