oracle 23c未增强物化视图增量刷新能力，fast refresh机制与19c/21c完全一致；新增的refresh concurrently仅支持complete模式且不降低耗时，json relational duality与刷新逻辑无关。
Oracle 23c 并未增强物化视图的增量刷新能力，FAST REFRESH 机制与 19c/21c 完全一致，ROWID 依赖、物化视图日志要求、查询限制等约束一个没少。所谓“新特性优化刷新性能”是个常见误解——23c 的 JSON Relational Duality、简化 SQL（如省略 FROM）等亮点，和物化视图刷新逻辑毫无交集。
为什么不能指望 23c 的 JSON Relational Duality 加速物化视图刷新？
JSON Relational Duality 解决的是“应用层用 JSON 写数据，数据库底层用关系表存数据”的映射同步问题，它不介入物化视图的变更捕获链路。物化视图日志（MATERIALIZED VIEW LOG）仍需显式创建，且只记录基表的 DML 变更；Duality 视图的更新走的是普通 INSERT/UPDATE 路径，不会自动触发物化视图日志写入，更不会被 REFRESH FAST 捕获。
换句话说：你用 Duality 视图改了数据，物化视图日志里什么都不会多出来，下次 REFRESH FAST 还是按老规矩查日志——结果就是漏刷。
23c 中真正影响物化视图刷新的兼容性变化只有这一处
Oracle 23c 引入了 REFRESH CONCURRENTLY（并发刷新）语法支持，但仅限于 COMPLETE 刷新模式，且必须满足：
- 物化视图定义中包含
BUILD IMMEDIATE或已存在数据 - 目标物化视图上建有唯一索引（非主键也可）
- 刷新时不阻塞对物化视图的 SELECT 查询（这是关键收益）
REFRESH MATERIALIZED VIEW mv_sales_summary CONCURRENTLY;
注意：CONCURRENTLY 不适用于 FAST 或 ON COMMIT 模式，也不降低 I/O 或 CPU 开销。
实际部署时最容易踩的坑
在 23c 环境下配置物化视图，以下三点比版本新旧更重要：
-
REFRESH FAST前必须确认基表已建好带ROWID和所需列的物化视图日志，缺一不可；否则报错ORA-12015: cannot create a fast refresh materialized view from a complex query - 即使用了
CONCURRENTLY，刷新失败后物化视图状态会变成BUILD FAILED，必须手动REFRESH COMPLETE恢复，不能靠重试自动修复 - 23c 的查询重写（
ENABLE QUERY REWRITE）默认仍为DISABLED，不显式开启就无法享受物化视图带来的透明加速
真正决定刷新性能的，从来不是 Oracle 版本号，而是物化视图日志是否精简（只含必要列）、基表是否有高效索引支撑日志维护、以及业务变更频率是否匹配 FAST 刷新的适用场景。23c 没给这条链路加任何“捷径”。
