• 表统计信息： 行数、块数、平均行长度。
• 列统计信息： 唯一值数量、空值数量、直方图。
• 索引统计信息： B-Level、叶子块数、聚簇因子。老实说，
• 程序统计信息： CPU 速度、单块读/多块读平均耗时。

. 如何收集统计信息？

BEGIN
DBMS_STATS.GATHER_TABLE_STATS(
ownname => 'SCOTT'。tabname => 'EMP',cascade => TRUE);-- 同时收集索引统计
END;/

⚠️ 注意：统计信息过时是执行计划变差的头号原因！如果你刚往表里灌了大量数据，但统计还是旧值。CBO 会误认为全表扫描很快，结果往往让人失望。

三、CBO 如何计算成本？拆解 Cost 的构成

. I/O 成本

• 单块读："TABLE ACCESS FULL" 时一次只读一个块；索引回表也属于随机 IO。
• 多块读： "FULL TABLE SCAN" 一次读多个块，成本更低。
• CBO 用程序参数 SREADTIM/MREADTIM 转换为时间，再换算成 I/O 成本。

. CPU 成本与网络成本

• CQL 等价 CPU 时间也被转换成等效 I/O 成本统一度量。
• "NETWORK COST" 通常被忽略，但在分布式查询中可能不可忽视。

简化公式：总成本 ≈ I/O 成本 + CPU 成本 + 网络成本

四、CBO 的“解题思路”：从 SQL 到执行计划

. 步骤概览

1. A解析与验证： 语法检查 + 权限校验 + 树生成。
2. B逻辑调整 ：
   • 视图合并 → 减少嵌套层级； 不过，
   • 谓词推进 → 提前过滤；
   • 子查询展开 → 把 IN/EXISTS 转为连接；
   • 星型转换 → 对维度条件使用位图访问。目标是产生更多候选方法，
3. C物理调整 ：
   • 枚举所有可行方法；
   • 动态规划剪枝避免穷举；话说回来，
   • 评估连接顺序 & 方法。最终选择最低总成本方法，
4. D生成最终执行计划交给引擎。

五、看懂执行计划的关键指标

ID / Operation / Name: 从内到外逐步阅读，缩进最多者先做。如果你发现某个步骤重复或无意义，那说明可能存一定要确认对象归属！

Rows:

: 数据量估算，用以判断 I/O 大小。若 Bytes 显著高于实际情况，则说明某一步读取了太多冗余数据。不过，💡 建议检查是否可以加上 WHERE 子句限制字段或改用位图索引等方式减少读取量。

):

: Estimated execution time. 仅供参考。由程序负载影响大，请结合实际监控指标进行验证。⚙️ 若实际延迟明显高于预估，可进一步排查网络延迟和锁等待问题。

从请注意来看，

• 当你看到 A-Rows 与 E-Rows 差距极大时就是 统计不准确 或 绑定变量窥视 的典型症状。
• 如果某个步骤返回 0 行但预计大量行，这通常代表着 谓词推送失败 或 直方图缺失。不过，

如果发现上述任何痛点。可以按以下方式快速定位和修复：

1️⃣ 手动收集相关表/列/索引直方图 sql BEGIN DBMS_STATS.GATHER_TABLE_STATS;DBMS_STATS.GATHER_HISTOGRAM;END，/

2️⃣ 开启 STATISTICS_LEVEL = ALL 并查看 DBMS_XPLAN.DISPLAY_CURSOR 这会把每一步真实行数 与预测行数 放在一起，让你一眼就能看出偏差来源。

3️⃣ 如需更细粒度调优，可利用 SQL Tuning Advisor 自动生成建议报告。

4️⃣ 最终如果仍然无法解决，可以尝试手动重写 SQL 或添加提示。如 /*+ INDEX */ 强制使用特定索引。但请先确认该提示不会造成新的性能瓶颈。

希望以上技巧能方便你定位并解决 Oracle CBO 带来的性能问题，并让你的 SQL 执行更加高效与可预测！