执行计划与DBMS_XPLAN
执行计划是 SQL 调优的事实依据。Oracle 计划不仅要看访问路径，还要看基数估算、连接顺序、连接方法、Predicate、实际行数和执行时统计。
# 1. 学习目标与定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 进阶到专家 |
| 核心目标 | 从底层运行链路理解本篇主题，能把概念、SQL、指标、故障和工程取舍连起来 |
| 适合人群 | 开发人员关注 SQL 写法如何影响计划；运维人员关注 SQL_ID、计划漂移、SQL Monitor 和运行时行源。 |
# 2. 核心概念总览
执行计划与DBMS_XPLAN
├─ EXPLAIN PLAN
├─ DBMS_XPLAN
├─ Access Path
├─ Join Order
├─ Join Method
├─ Predicate Information
├─ Cardinality
├─ Cost
└─ SQL Monitor
这张图只用来定位本章范围。正文不会把每个词机械拆成固定问答，而是按 Oracle 的真实运行机制解释它们之间如何协作、在哪里影响开发、在哪里影响运维。
# 3. 底层原理详解
Oracle 执行计划是行源树。每个节点产生一批行，传给上层节点继续过滤、连接、排序或聚合。调优要看数据如何从底层对象一步步流动到最终结果。
EXPLAIN PLAN 只是优化器预估计划，不一定等于真实执行计划。DBMS_XPLAN.DISPLAY_CURSOR 可以查看游标实际执行计划，配合 ALLSTATS LAST 能看到估算行数和实际行数差异。
成本 Cost 不是耗时，Cardinality 也只是估算。真正有价值的是估算与实际的偏差、访问路径是否合理、连接方法是否匹配数据量、Predicate 是否落在正确层级。
# 4. 关键机制拆解
# 4.1. 计划来源和查看方式
EXPLAIN PLAN 不执行 SQL，只生成预估计划；DISPLAY_CURSOR 查看共享池中真实游标；AWR 可以查看历史计划；SQL Monitor 适合长 SQL 和并行 SQL 运行时观察。
调优时优先拿真实执行计划和实际执行统计。只凭 EXPLAIN PLAN 做结论，很容易被绑定变量、权限、会话参数和统计信息差异误导。
# 4.2. 访问路径和谓词信息
Access Path 包括全表扫描、索引范围扫描、唯一扫描、快速全索引扫描、ROWID 访问等。Predicate Information 会告诉条件是 access 还是 filter。
access 谓词用于定位数据，filter 谓词用于拿到数据后再过滤。大量过滤发生在访问之后，通常意味着索引或谓词设计不够好。
# 4.3. 连接顺序和连接方法
Join Order 决定先处理哪些表，Join Method 决定如何连接。Nested Loops 适合小结果驱动索引访问，Hash Join 适合大集合连接，Sort Merge Join 适合已排序或特定条件。
基数估算错误会导致连接顺序错误。一个表估算 10 行实际 1000 万行，后续所有选择都可能错。
# 4.4. 估算、实际和 SQL Monitor
ALLSTATS LAST 能暴露 E-Rows 与 A-Rows 差异。SQL Monitor 则能看到运行时耗时、并行分布、临时空间和行源进度。
专家调 SQL 时会把计划树、对象统计、绑定变量、等待事件和业务参数放在一起，而不是只看“用了哪个索引”。
# 5. 功能模块细节补充
本节围绕概念图中的模块逐个补充底层细节，重点讲它们在 Oracle 运行链路中的位置和相互关系，而不是按固定角色模板拆分。
# 5.1. EXPLAIN PLAN
EXPLAIN PLAN 是优化器决策或执行计划证据的一部分。调优时要看它如何影响基数估算、访问路径、连接顺序、连接方法和运行时统计；只看 Cost 或只看是否用了索引都不够。
# 5.2. DBMS_XPLAN
DBMS_XPLAN 是优化器决策或执行计划证据的一部分。调优时要看它如何影响基数估算、访问路径、连接顺序、连接方法和运行时统计；只看 Cost 或只看是否用了索引都不够。
# 5.3. Access Path
Access Path 是优化器决策或执行计划证据的一部分。调优时要看它如何影响基数估算、访问路径、连接顺序、连接方法和运行时统计；只看 Cost 或只看是否用了索引都不够。
# 5.4. Join Order
Join Order 是 SQL 表达能力的一部分。它不是单纯语法糖，而会改变优化器改写空间、中间结果规模、访问路径、排序哈希和临时空间消耗；复杂 SQL 必须用真实执行计划和行数验证。
# 5.5. Join Method
Join Method 是 SQL 表达能力的一部分。它不是单纯语法糖，而会改变优化器改写空间、中间结果规模、访问路径、排序哈希和临时空间消耗；复杂 SQL 必须用真实执行计划和行数验证。
# 5.6. Predicate Information
Predicate Information 是优化器决策或执行计划证据的一部分。调优时要看它如何影响基数估算、访问路径、连接顺序、连接方法和运行时统计；只看 Cost 或只看是否用了索引都不够。
# 5.7. Cardinality
Cardinality 是优化器决策或执行计划证据的一部分。调优时要看它如何影响基数估算、访问路径、连接顺序、连接方法和运行时统计；只看 Cost 或只看是否用了索引都不够。
# 5.8. Cost
Cost 是优化器决策或执行计划证据的一部分。调优时要看它如何影响基数估算、访问路径、连接顺序、连接方法和运行时统计；只看 Cost 或只看是否用了索引都不够。
# 5.9. SQL Monitor
SQL Monitor 是 SQL 表达能力的一部分。它不是单纯语法糖，而会改变优化器改写空间、中间结果规模、访问路径、排序哈希和临时空间消耗；复杂 SQL 必须用真实执行计划和行数验证。
# 6. 开发人员重点提醒
- 上线 SQL 要提供真实执行计划，不只贴 SQL 文本。
- 关注实际返回行数和中间行数，避免中间结果爆炸。
- 绑定变量样本要能代表真实业务分布。
# 7. 运维人员重点提醒
- 保留核心 SQL 的 SQL_ID、Plan Hash 和 AWR 历史。
- 使用 DBMS_XPLAN 和 SQL Monitor 定位行源瓶颈。
- 关注估算行数与实际行数偏差。
# 8. 典型问题与排查
- 计划很好但仍慢：检查等待事件、并发、IO 和返回数据量。
- 估算严重偏差：检查统计信息、直方图、表达式和数据倾斜。
- 计划频繁变化：检查绑定变量、统计信息刷新和自适应特性。
# 9. 实践建议与检查清单
- 使用真实游标计划
- E-Rows/A-Rows 已对比
- Predicate 已分析
- 连接顺序合理
- SQL Monitor 可用于长 SQL
# 10. 阶段小结
本篇的学习重点不是记住术语，而是能把底层机制、业务语义和生产证据连起来。读完本篇后，应该能解释关键组件如何协作、常见问题为什么发生、开发侧如何避免制造风险、运维侧如何用指标和日志把问题定位到具体链路。