SQL执行计划如何分析_完整逻辑拆解助力系统化掌握【技巧】

执行计划分析需建立“查询意图→物理路径→性能瓶颈”闭环逻辑，核心是树形结构自底向上解读、盯住代价偏差、实测验证假设、回归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，或刚重启库还没预热。

验证假设：别信计划，要测行为

执行计划是优化器的“预测稿”，真实表现还得靠实测。三个低成本验证动作：

标签： mysql oracle ai 性能瓶颈 cos 隐式类型转换 为什么 red