刷新物化视图后必须立即执行dbms_stats.gather_table_stats（含cascade=>true）更新其统计，否则优化器因使用过期统计导致执行计划错误；需确认last_analyzed时间晚于刷新时间，并避免依赖gather_schema_stats。
刷新后必须立刻收集统计信息，不能等自动任务
Oracle 11g 的 DBMS_STATS.GATHER_SCHEMA_STATS 或夜间自动任务默认不覆盖物化视图（MV），哪怕基表刚更新过统计，MV 自身的统计仍停留在刷新前。优化器查 MV 时只看 DBA_TAB_STATISTICS 里对应 MV 名的记录，旧统计会导致 TABLE ACCESS FULL、PARTITION RANGE ALL 等错误执行路径。
确认是否遗漏：运行 SELECT LAST_ANALYZED, NUM_ROWS FROM DBA_TAB_STATISTICS WHERE TABLE_NAME = 'YOUR_MV_NAME'，若 LAST_ANALYZED 时间早于最近一次刷新时间，就是问题根源。
- 必须对物化视图名（或预建表名）直接执行
DBMS_STATS.GATHER_TABLE_STATS，不是基表名 - 如果 MV 建在预建表上（
ON PREBUILT TABLE），统计要收集到那个物理表名，不是 MV 名 - 不要依赖
GATHER_SCHEMA_STATS—— 它通常跳过 MV 对象
必须加 cascade => TRUE，否则索引统计不生效
物化视图上的本地索引（如分区索引）和主键索引是独立对象，DBMS_STATS.GATHER_TABLE_STATS 默认不更新它们的统计。即使表级统计更新了，索引仍处于“不可见”状态，优化器可能拒绝使用。
典型表现：执行计划里看到 INDEX RANGE SCAN，但 ACCESS PREDICATES 为空，或 ROWS 估算严重失真（比如显示 1 行，实际返回 10 万行）。
- 调用时务必显式指定
cascade => TRUE：DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA_NAME', tabname => 'MV_NAME', cascade => TRUE) - 不加
cascade，索引统计不会被更新，DBA_IND_STATISTICS中对应索引的LAST_ANALYZED时间不变 - 如果 MV 含大量分区，可配合
degree => 4加速，但避免estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE导致超时
避免用 FOR ALL COLUMNS SIZE AUTO，按需指定列
物化视图结构固定、查询模式明确，用通用采样策略反而引入噪声。比如对只有 Y/N 的标志列做直方图，会让优化器误判选择性；而对高频过滤列（如 CUSTOMER_ID、SALES_MONTH）漏掉直方图，又会导致范围谓词估算偏差。
实操建议：用 method_opt 精确控制，例如：
method_opt => 'FOR COLUMNS SIZE 254 CUSTOMER_ID, SALES_MONTH, PRODUCT_CATEGORY'
-
SIZE 254表示为这些列收集频率直方图（适用于高选择性列） - 避开表达式列（如
TRUNC(SALE_DATE)）——MV 里存的是计算结果，应针对存储后的列建统计 - 如果 MV 含聚合字段（如
SUM(QTY)），无需为它建直方图，除非该字段常用于WHERE过滤
刷新失败后重试前，先检查 STALENESS 和日志
执行 DBMS_STATS.GATHER_TABLE_STATS 报错或无效，常见原因是 MV 处于 STALE 状态且基表变更触发了重写路径异常，或物化视图日志损坏导致刷新链中断。
先查基础状态：
SELECT MVIEW_NAME, STALENESS, STALENESS_REASON FROM USER_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV_NAME';
-
STALENESS = 'STALE'时，QUERY REWRITE可能被禁用，统计收集也无效 —— 必须先成功刷新 MV -
STALENESS_REASON显示UNDEFINED或FAILED，说明上次刷新失败，需查DBA_MVIEW_ANALYSIS或V$MVREFRESH日志 - 若日志缺失关键列（如漏了
ROWID或分区表达式列），快速刷新会退化为完全刷新，此时统计收集必须等刷新完成后再做
统计信息不是万能解药——它只在 MV 数据可用、状态为 FRESH 且索引有效时才起作用。刷新卡住或索引 UNUSABLE，先解决这些底层问题，再收集统计。
