基表新增分区后物化视图STALENESS变为UNUSABLE，因ADD PARTITION属DDL不写入日志且破坏结构契约；须先ALTER MATERIALIZED VIEW ... COMPILE，再收集统计信息，否则刷新失败且查询重写失效。
基表新增分区后，物化视图不会自动感知，是因为物化视图的元数据和刷新逻辑不监听分区 DDL 事件——它只依赖物化视图日志（MLOG$_xxx）和编译状态，而 ADD PARTITION 这类操作既不写入日志，也不触发 MV 自动重编译。
为什么 ADD PARTITION 不进物化视图日志
物化视图日志只捕获 DML（INSERT/UPDATE/DELETE），不捕获 DDL。即使日志建了 INCLUDING NEW VALUES，ADD PARTITION 本身不产生行级变更，日志表 MLOG$_base_table 的行数仍为 0。Oracle 无法从中推导出“新分区有数据”，也就不会在 FAST 刷新时扫描该分区。
- 验证方法：
SELECT COUNT(*) FROM MLOG$_base_table—— 若基表刚加了分区且没做 DML，结果必为 0 -
EXCHANGE PARTITION同样不进日志，除非交换后显式对目标分区执行 DML - 唯一能被日志捕获的分区相关操作，是
INSERT /*+ APPEND */到新分区的语句（但前提是日志含ROWID且未被MOVE失效）
物化视图编译状态断裂导致 STALENESS=UNUSABLE
ADD PARTITION 是隐式提交操作，会破坏物化视图与基表之间的结构契约。Oracle 检测到基表分区拓扑变化后，将 STALENESS 置为 UNUSABLE，而非 STALE，表示“不再信任当前定义”，此时连 REFRESH FAST 都被拒绝。
- 查状态：
SELECT MVIEW_NAME, STALENESS, STALENESS_REASON FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_NAME' - 必须先执行：
ALTER MATERIALIZED VIEW mv_name COMPILE—— 跳过这步直接刷新会报ORA-12008或静默失败 - 编译成功后，
STALENESS通常变为STALE，才可继续REFRESH FAST
PCT 失效：新分区无法参与分区变更跟踪
即使编译通过，PCT（Partition Change Tracking）也不会自动覆盖新增分区。PCT 依赖物化视图创建时已知的分区边界，运行时不会动态加载新分区元数据。
- 现象：
DBMS_MVIEW.EXPLAIN_MVIEW显示REFRESH_FAST_PCT = 'N'，或刷新时回退到 COMPLETE - 根本原因：基表新增分区后，物化视图未重建或未显式同步分区映射；
PCT要求基表分区定义在 MV 创建时就固定 - 临时解法：对新分区手动执行一次
REFRESH FAST（需确保该分区有 DML 记录在日志中） - 长期解法：若频繁增删分区，改用
ON PREBUILT TABLE+ 手动分区的物化视图，并定期DBMS_MVIEW.REFRESH_ALL_MVIEWS同步
查询重写失效：优化器无法把谓词映射到新分区
即使物化视图数据已刷新，查询重写（QUERY REWRITE）也可能失败。因为优化器校验重写条件时，会比对查询谓词与物化视图分区键表达式是否“语义等价”，而新增分区可能引入边界偏移或 NLS 设置差异。
- 典型信号：
EXPLAIN PLAN显示走基表，但DBMS_MVIEW.EXPLAIN_MVIEW返回QSMQT_UNREWRITE - 检查点：
SELECT COLUMN_NAME FROM USER_TAB_PARTITIONS WHERE TABLE_NAME = 'MV_NAME'—— 确认物化视图实际分区列是否与基表一致 - 修复动作：对物化视图执行
DBMS_STATS.GATHER_TABLE_STATS(..., GRANULARITY => 'ALL')，强制更新分区级统计信息
最易被忽略的是：编译（COMPILE）和统计信息收集（GATHER_TABLE_STATS）这两步必须都做，缺一不可。只编译不收集，CBO 仍按旧基数估算；只收集不编译，刷新直接被拦在门外。
