分区键变更后REFRESH FAST是否生效取决于PCT能力是否保留：仅当基表为RANGE/LIST单列分区、分区键在MV中以原始列名显式出现时才支持；若改为HASH/复合分区、加函数包装或重命名列，PCT失效，REFRESH FAST退化为COMPLETE。
物化视图是否还能快速刷新（REFRESH FAST）
分区键变更后，REFRESH FAST 是否继续生效，取决于变更是否破坏了 PCT（Partition Change Tracking）能力。PCT 要求：基表必须是 RANGE 或 LIST 分区、分区键为单列、且该列在物化视图的 SELECT 和 GROUP BY 中以原始列名形式**显式出现**。
常见破坏场景：
- 把
sale_date分区键改成TRUNC(sale_date, 'mm')→ 物化视图定义若仍用sale_date，则REFRESH_FAST_PCT = 'N' - 原按
region_idLIST 分区，改为按(region_id, country_code)复合分区 → 不再满足单列约束，PCT 直接禁用 - 分区键列被重命名（如
ALTER TABLE t RENAME COLUMN dt TO sale_dt）→ 物化视图定义未同步更新，刷新时无法对齐分区元数据
验证方式：运行 DBMS_MVIEW.EXPLAIN_MVIEW('mv_name')，查输出中 REFRESH_FAST_PCT 字段值；或刷新后查 V$MVREFRESH，看 REFRESH_TYPE 是 FAST 还是 COMPLETE。
查询重写（QUERY REWRITE）是否失效
物化视图能否被优化器自动选用，关键看查询与 MV 定义之间是否存在「语义断层」。分区键变更后，如果新分区表达式与查询中的过滤条件不严格等价，重写就会失败，表现为 EXPLAIN PLAN 显示走基表而非 MV，且 DBMS_MVIEW.EXPLAIN_MVIEW 返回 QSMQT_UNREWRITE。
典型断层点：
- 基表改用
TO_CHAR(order_time, 'YYYYMMDD')分区，但查询写的是order_time >= DATE '2024-01-01'→ Oracle 无法证明两者逻辑等价 - 分区键类型隐式转换，如原
NUMBER分区键改为VARCHAR2(10)，而查询中用数字字面量比较 → 触发隐式转换，破坏表达式匹配 - 物化视图定义里用了别名（
SELECT order_time AS dt FROM t），而查询条件写dt >= ...→ 优化器不识别别名与物理分区列的映射
修复前务必检查 USER_TAB_PARTITIONS 中的 COLUMN_NAME，它反映的是实际物理分区列，不是 SELECT 列表里的别名。
物化视图日志是否还有效
分区键变更本身不直接影响日志结构，但若伴随表结构变更（如删列、改类型、重建分区），原有物化视图日志可能失效或不再覆盖新分区键列。
需确认三点：
-
USER_MVIEW_LOGS中对应日志的LOG_TABLE是否仍存在且状态正常（STATUS = 'VALID'） - 日志是否包含新分区键列：例如原日志建在
WITH ROWID, SEQUENCE(sale_date)，但分区键已改为sale_month，则需补上SEQUENCE(sale_month) - 若基表从 RANGE 改为 HASH 分区：日志虽能建，但
REFRESH FAST必然退化为COMPLETE，因 HASH 不支持 PCT —— 这是硬性限制，无法绕过
执行 SELECT * FROM USER_MVIEW_LOGS WHERE MASTER = 'T_NAME' 可快速核对日志字段和选项。
统计信息是否需要强制更新
分区键变更后，物化视图的分区结构、行分布、空闲空间都可能变化，旧统计信息会导致 CBO 成本估算严重失真，表现为：明明可走 MV 却选了基表全扫，或走 MV 后因基数误判引发嵌套循环爆炸。
必须立即执行：
-
DBMS_STATS.GATHER_TABLE_STATS对物化视图本身，且指定GRANULARITY => 'ALL'（确保采集每个分区的统计） - 同步采集基表统计，尤其注意
LAST_ANALYZED时间戳是否一致（查USER_TAB_STATISTICS） - 若物化视图含聚合，还需收集列级统计（
METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO'），否则 GROUP BY 列的 NDV（distinct values）可能不准
忽略这步，即使语法和逻辑都正确，也可能因成本误判导致查询性能雪崩——这是最隐蔽也最容易被跳过的环节。
