Oracle 23c并未放宽多表连接物化视图的语法限制，仍要求连接列具备已验证的主键/外键约束且所有引用列须在物化视图日志中显式声明；其改进在于优化器更可能重写因约束或日志缺失而被跳过的查询。
Oracle 23c是否放宽了多表连接物化视图的语法限制？
没有。create materialized view 语句对多表连接的语法约束本身未变——仍要求连接列必须有已验证的主键/外键约束，且所有被引用列需在物化视图日志中显式声明。23c 的改进不体现在“允许你写更松散的 sql”，而在于让优化器更可能重写那些原本因约束缺失或日志不全而被跳过的查询。
QUERY_REWRITE_INTEGRITY=TRUSTED 在 23c 中是否真正可用？
是，但需谨慎。23c 继续支持 QUERY_REWRITE_INTEGRITY=TRUSTED 模式，它允许绕过基表约束验证，启用重写。但这不是“自动修复”，而是把责任交给你：
• 必须手动确保基表数据逻辑上满足完整性（例如业务侧保证外键关系）
• DBMS_MVIEW.EXPLAIN_REWRITE 输出里若出现 integrity violation，切勿直接调高该参数掩盖问题
• 金仓等 Oracle 兼容库在 TRUSTED 模式下行为可能不一致，生产环境建议始终用 ENFORCED + 真实约束
23c 自动物化视图能否绕过多表连接的刷新瓶颈？
不能绕过，但能暴露瓶颈。23c 的自动生成建议会分析历史 SQL 执行计划，若发现某个多表连接频繁出现 HASH JOIN 且驱动表小、被驱动表大，它可能推荐一个含该连接的物化视图——但该物化视图仍需满足：
• 每张基表都有带 SEQUENCE 的物化视图日志（缺一不可）
• 刷新时若某张基表无日志，REFRESH FAST 直接退化为 COMPLETE，且 DBMS_MVIEW.REFRESH 不报错也不提示降级
• 自动建议不会检查权限，CREATE MATERIALIZED VIEW LOG 失败时仅记录警告，容易漏掉
为什么执行计划里看到物化视图名，但实际没走它？
常见于 23c 的新执行路径判断逻辑：
• 即使 QUERY_REWRITE_ENABLED=TRUE，若物化视图统计信息陈旧（LAST_ANALYZED 滞后于最近一次 REFRESH），优化器可能弃用它
• 多表连接物化视图若含 COUNT(*) 或 SUM(column)，但基表日志未包含 INCLUDING NEW VALUES，重写会被静默禁用
• EXPLAIN PLAN FOR 显示物化视图名 ≠ 实际执行路径；必须查 V$SQL_PLAN.OBJECT_NAME 或用 autotrace on explain 确认真实访问对象
真正关键的不是“23c 能不能做”，而是“你有没有让每张基表的日志、约束、统计信息、会话参数全部对齐”。少一个环节，重写就失效，而且失效得悄无声息。
