如何利用Oracle 19c的实时统计信息收集优化PL/SQL？-Oracle-PHP中文网

oracle 19c实时统计对pl/sql优化无直接作用，仅影响dml后sql解析的基数估算；pl/sql静态sql复用游标依赖传统dbms_stats统计，execute immediate动态sql才可能间接受益。

oracle 19c 的实时统计信息收集（real-time statistics）对 pl/sql 优化几乎**没有直接作用**，它不参与 pl/sql 编译、绑定变量窥探或运行时执行计划选择——这些仍完全依赖传统 dbms_stats 收集的静态统计信息。

实时统计只影响 DML 后的查询优化器估算，不改变 PL/SQL 执行逻辑

实时统计是 Oracle 在执行 INSERT/UPDATE/DELETE 时，自动更新 DBA_TAB_STATISTICS 和 DBA_TAB_COL_STATISTICS 中部分字段（如 NUM_ROWS、NUM_DISTINCT）的轻量机制，仅用于后续 SQL 解析阶段的基数估算。PL/SQL 块内嵌的 SQL 语句是否重硬解析、是否复用游标、是否使用绑定变量，全由共享池状态和传统统计信息决定。

即使你刚插入 100 万行，实时统计立刻刷新了 NUM_ROWS，但 PL/SQL 中已缓存的游标不会自动失效或重生成执行计划
EXECUTE IMMEDIATE 动态 SQL 会触发新解析，此时才可能受益于实时统计；而静态 SQL（如 SELECT ... INTO）复用已有游标，完全无视实时值
PL/SQL 函数内联、优化器转换（如谓词推入、视图合并）等行为，均基于 DBA_TAB_STATISTICS 中 GLOBAL_STATS = 'YES' 的传统统计，而非实时字段

哪些 PL/SQL 场景可能“间接”受益？

只有当 PL/SQL 中的 SQL 语句在每次调用时都触发硬解析，且数据变更频繁到传统统计来不及更新时，实时统计才可能带来微弱改善。典型场景极少，需同时满足：

使用 EXECUTE IMMEDIATE + 拼接 SQL（无绑定变量），且拼接逻辑导致每次 SQL 文本不同
表在 PL/SQL 运行期间被高频 DML 修改（如批处理循环中每轮 INSERT 后立即 SELECT）
该表未启用增量统计（INCREMENTAL = TRUE），传统自动任务又滞后，导致 NUM_ROWS 严重失真
查询谓词高度依赖行数估算（如 WHERE ROWNUM 或连接顺序敏感的多表 JOIN）

注意：NOTES 列显示 STATS_ON_CONVENTIONAL_DML 仅表示实时统计已启用并记录过变更，不代表当前值已被优化器采纳——必须配合硬解析才生效。

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

别把实时统计当“自动优化开关”，它甚至不能替代一次 GATHER_TABLE_STATS

实时统计不是全量统计，它不收集直方图、不更新 CLUSTERING_FACTOR、不计算索引叶块数，更不触发表级 AVG_ROW_LEN 或列级 DENSITY。常见误操作包括：

看到 NOTES = 'STATS_ON_CONVENTIONAL_DML' 就认为统计“已最新”，结果执行计划仍走错索引
禁用自动任务后依赖实时统计维持性能，导致大分区表全局 NUM_DISTINCT 长期不准（实时统计用 HyperLogLog 估算，但只覆盖变更列，非全量）
在 PL/SQL 包初始化块里调用 DBMS_STATS.LOCK_TABLE_STATS，却忘了实时统计无法被锁定——DML 仍会偷偷改写 NUM_ROWS，引发计划漂移

真正该在 PL/SQL 中控制的，是传统统计的触发时机

若业务逻辑明确知道某次 DML 后统计必然失真（如 TRUNCATE + INSERT APPEND 加载千万级分区），应在 PL/SQL 中主动触发精准收集，而非等待实时或自动任务：

BEGIN
  EXECUTE IMMEDIATE 'TRUNCATE TABLE sales_part';
  INSERT /*+ APPEND */ INTO sales_part SELECT * FROM staging_sales;
  COMMIT;
<p>-- 关键：立刻补全统计，避免后续查询用错计划
DBMS_STATS.GATHER_TABLE_STATS(
ownname     => 'SH',
tabname     => 'SALES_PART',
granularity => 'ALL',      -- 必须 ALL，否则只扫新分区
method_opt  => 'FOR ALL COLUMNS SIZE AUTO',
degree      => 4
);
END;</p>

这里 granularity => 'ALL' 是关键——实时统计从不提供分区级摘要合成能力，只有显式 GATHER_TABLE_STATS 配合 INCREMENTAL = TRUE 才能安全更新全局统计。忽略这点，PL/SQL 再怎么“实时”，优化器看到的仍是陈旧的 GLOBAL_STATS = 'NO' 状态。