Oracle 19c物化视图不支持分析函数，因其破坏增量刷新语义；绕过方法为嵌套物化视图（聚合后加分析函数）或预计算临时表+手动调度，均需DBMS_MVIEW.EXPLAIN_MVIEW验证。
oracle 19c 的物化视图不支持直接在定义中使用分析函数（如 row_number()、rank()、lead() 等），这是硬性限制，不是配置或权限问题。
为什么物化视图里不能写 ROW_NUMBER() OVER (PARTITION BY ...)？
Oracle 查询重写器和快速刷新引擎对 SQL 结构有严格校验。分析函数会破坏“可增量维护”的语义基础——因为它的输出依赖于整个窗口数据集，无法仅靠物化视图日志里的单行变更推导出新值。即使你用 REFRESH COMPLETE，建 MV 时也会报错：ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view（尤其当尝试 ON COMMIT 时），或在 DBMS_MVIEW.EXPLAIN_MVIEW 中看到 FAST REFRESHABLE = NO。
常见错误现象包括：
- 执行
CREATE MATERIALIZED VIEW报ORA-32313或ORA-12054 - 虽创建成功，但
DBA_MVIEWS.REFRESH_METHOD显示为COMPLETE，且无法启用FAST或QUERY REWRITE - 即使强制设
ENABLE QUERY REWRITE，EXPLAIN PLAN和DBMS_MVIEW.EXPLAIN_REWRITE均显示UNREWRITTEN
绕过限制的两种实操路径：嵌套物化视图 vs 预计算临时表
核心思路是把分析逻辑从 MV 定义中剥离，转到可被 MV 消费的上游层。
推荐优先用「嵌套物化视图」，前提是你的分析函数只依赖聚合后结果（比如按天汇总后再排 Top N）：
- 第一层 MV：先做聚合（不含分析函数），例如
CREATE MATERIALIZED VIEW mv_daily_sales AS SELECT TRUNC(sale_time, 'DD') dt, region, SUM(amount) amt FROM sales GROUP BY TRUNC(sale_time, 'DD'), region - 第二层 MV：基于第一层构建，加分析函数，例如
CREATE MATERIALIZED VIEW mv_daily_top3 AS SELECT dt, region, amt, ROW_NUMBER() OVER (PARTITION BY dt ORDER BY amt DESC) rn FROM mv_daily_sales - 注意：第二层必须用
REFRESH COMPLETE，且不能启用QUERY REWRITE（因含分析函数）；但第一层可设FAST刷新，仍能加速原始查询中的聚合部分
若分析逻辑强依赖明细行（如 LAG(amount) OVER (ORDER BY sale_id)），嵌套 MV 不适用，改用「预计算临时表 + 手动调度」：
- 建普通表
stg_sales_with_lag，每天定时用 PL/SQL 调用INSERT /*+ APPEND */ INTO stg_sales_with_lag SELECT ..., LAG(...) OVER (...) FROM sales WHERE sale_time >= TRUNC(SYSDATE) - 7 - 再基于该表建一个标准 MV（无分析函数），用于下游报表查询：
CREATE MATERIALIZED VIEW mv_sales_lag_summary AS SELECT region, AVG(lag_diff) FROM stg_sales_with_lag GROUP BY region - 关键点：临时表需手动
TRUNCATE+INSERT，不可依赖 MV 自动刷新机制
DBMS_MVIEW.EXPLAIN_MVIEW 是唯一可信的验证手段
别信 EXPLAIN PLAN 是否走 MV —— 它根本不会显示分析函数相关的重写失败原因。真正要看的是：
- 对含分析函数的 MV 执行
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('mv_daily_top3') - 查
MVIEW_EXCEPTIONS表，重点看RECOMMENDATION字段是否含"ANALYTIC FUNCTIONS NOT SUPPORTED" - 对想重写的报表 SQL，必须跑
DBMS_MVIEW.EXPLAIN_REWRITE并检查REWRITE_MECHANISM，TEXT_MATCH才算真生效
容易忽略的坑是：即使嵌套 MV 第二层不能重写，第一层仍可能被优化器用于加速原始查询中的 GROUP BY 部分——但这个加速效果不会出现在 EXPLAIN PLAN 的最终执行计划里，得靠 EXPLAIN_REWRITE 分步验证。
分析函数不是语法糖，它让 MV 失去增量能力。所有绕过方案本质都是把“不可维护”部分切出来人工兜底，而不是假装 Oracle 支持它。
