Oracle 19c 禁用含自连接物化视图的FAST刷新，因日志无法区分同一表多别名的行变更；EXPLAIN_MVIEW返回REFRESH_FAST=‘N’并提示“self join not supported”；可行替代方案是通过两层物化视图拆解自连接逻辑。
Oracle 19c 不支持任何含自连接（self-join）的物化视图进行 FAST 刷新——这不是配置疏漏，而是内核级硬限制。只要 SELECT 中出现同一张表被多次引用（如 FROM emp e1, emp e2 或 JOIN emp e1 ON e1.mgr = e2.empno），DBMS_MVIEW.EXPLAIN_MVIEW 就会返回 fastrefreshable = 'N'，刷新时静默退化为 COMPLETE。
为什么自连接直接禁用 FAST 刷新
快速刷新依赖物化视图日志（mlog$_table）中可精确映射的行级变更，而自连接破坏了这种映射的唯一性：
- 同一张物理表在查询中出现多次（
e1和e2），但日志只有一份，无法区分“哪一行变更对应哪个别名实例” - 刷新引擎无法确定：某次
UPDATE emp SET mgr = 100 WHERE empno = 200，该影响e1还是e2，还是两者都影响？更无法推导出增量结果集变化边界 - Oracle 不做语义解析，仅做语法扫描；一旦检测到同一基表名在
FROM子句中重复出现，立即关闭FAST路径
DBMS_MVIEW.EXPLAIN_MVIEW 显示什么
执行后查 MVIEW_EXCEPTIONS 或输出结果，关键字段会明确提示：
-
CAPABILITY_NAME = 'REFRESH_FAST'对应的POSSIBLE = 'N' -
MSGTXT包含类似"self join not supported for fast refresh"或"duplicate table reference"（不同版本措辞略有差异，但含义一致） - 不会报错建 MV，也不会在
CREATE时警告；问题只在REFRESH运行时暴露
替代方案：用物化视图嵌套绕过自连接
不能直接写 emp e1 JOIN emp e2，但可通过两层物化视图拆解逻辑：
- 第一层：
CREATE MATERIALIZED VIEW mv_emp_mgr AS SELECT empno, mgr FROM emp;（确保源表有日志：WITH PRIMARY KEY, SEQUENCE(empno, mgr) INCLUDING NEW VALUES） - 第二层：
CREATE MATERIALIZED VIEW mv_emp_self AS SELECT e.empno, e.ename, m.ename mgr_name FROM emp e, mv_emp_mgr m WHERE e.mgr = m.empno;（注意：这里mv_emp_mgr是物化视图，不是视图；它本身可FAST刷新，且其日志由 Oracle 自动管理） - 必须为
mv_emp_mgr单独启用REFRESH FAST ON DEMAND，并保证其刷新频率不低于上层依赖 - 该方案本质是把“自连接”转为“基表 → 物化视图 → 关联”，避开内核对重复基表名的拦截
容易被忽略的陷阱
即使嵌套方案可行，以下三点极易踩坑：
-
mv_emp_mgr若未显式指定REFRESH FAST（只写REFRESH ON DEMAND默认是COMPLETE），上层刷新仍会因数据陈旧而失败或结果错乱 - 嵌套 MV 的刷新顺序必须手动控制（如用
DBMS_MVIEW.REFRESH指定顺序），Oracle 不自动维护依赖链 - 如果原始自连接含
WHERE过滤（如WHERE e1.deptno = e2.deptno AND e2.sal > 5000），第二层 MV 的SELECT必须把过滤条件下推到第一层定义中，否则无法保障一致性
