物化视图含 DISTINCT 就不支持 FAST 刷新，因 DISTINCT 破坏增量变更的一对一映射关系，导致无法逆推日志变更；唯一解法是改用 GROUP BY 替代、嵌套物化视图或接受 COMPLETE 刷新并优化执行。
物化视图含 DISTINCT 就不支持 FAST 刷新
oracle 官方明确限制：只要物化视图定义中出现 distinct，就无法启用快速刷新（fast），dbms_mview.explain_mview 会直接返回 "refresh fast is not possible"。这不是配置问题，也不是参数能绕过的限制——它是内核级硬性约束。
为什么 DISTINCT 破坏了 FAST 刷新的数学基础
FAST 刷新依赖“增量变更可逆推”：日志里每条 INSERT/UPDATE/DELETE 记录，必须能一对一映射到物化视图行的增删改。而 DISTINCT 天然破坏这种映射关系：
- 基表插入 10 行重复数据 → 物化视图只新增 1 行，但日志无法标识“这 1 行对应哪 10 行的去重结果”
- 基表删除某行 → 若该行值在物化视图中仍由其他行支撑，物化视图实际不删；反之，若删的是唯一值，才删。日志无法预判这种依赖
-
GROUP BY+COUNT(*)这类聚合尚可建模，但DISTINCT没有等价的增量代数表达式
替代方案不是调参，而是重构查询逻辑
试图用 atomic_refresh => FALSE 或加大 parallelism 来“加速 DISTINCT 的 COMPLETE 刷新”，只是缓解症状，不解决本质。真正可行的路只有两条：
- 改用
GROUP BY替代DISTINCT：例如SELECT DISTINCT col1, col2 FROM t改为SELECT col1, col2 FROM t GROUP BY col1, col2—— 这样就能建日志、走 FAST，前提是基表有主键或 ROWID 且日志含所有 SELECT 列 - 用物化视图嵌套：外层物化视图不含
DISTINCT，内层先做聚合/去重计算并存为中间表，外层再查它；但需手动维护刷新链，且中间表统计信息必须及时更新 - 放弃 FAST，接受 COMPLETE 刷新，但必须开启
atomic_refresh => FALSE避免长事务，并配parallelism => 2~4加速 TRUNCATE+INSERT
最容易被忽略的验证点：EXPLAIN_MVIEW 输出必须看
别等 DBMS_MVIEW.REFRESH('mv_name', 'F') 跑了半小时才发现是 COMPLETE —— 每次修改物化视图定义后，第一件事就是执行：
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_WITH_DISTINCT');
然后查 MVIEW_EXCEPTIONS 或输出表里的 MSGTXT 字段。如果看到 "POTENTIAL FAST REFRESH"，说明还有戏；一旦出现 "REFRESH FAST IS NOT POSSIBLE"，立刻停手，回头重构 SQL。这个检查比调任何参数都关键。
