物化视图需同时开启全局QUERY_REWRITE_ENABLED参数和对象级ENABLE QUERY REWRITE，且满足语义等价、状态合法、统计信息完备、权限充足等条件，执行计划中出现MATERIALIZED VIEW REWRITE才表明重写生效。
物化视图必须显式启用 QUERY REWRITE 才能被自动路由
oracle 默认关闭查询重写功能，即使你建好了物化视图、加了 enable query rewrite 子句，数据库也不会自动把原 sql 重定向过去——除非全局开关和对象级开关都打开。
-
ALTER SYSTEM SET QUERY_REWRITE_ENABLED = TRUE;（或TRUE/FORCE，FORCE会忽略物化视图的禁用设置） - 物化视图创建时需带
ENABLE QUERY REWRITE，例如：CREATE MATERIALIZED VIEW mv_sales_sum<br> ENABLE QUERY REWRITE<br> AS SELECT region, SUM(amount) FROM sales GROUP BY region;
- 若物化视图已存在但没启用重写，得重建或用
ALTER MATERIALIZED VIEW mv_sales_sum ENABLE QUERY REWRITE; - 注意：
QUERY_REWRITE_INTEGRITY参数影响匹配严格度，默认ENFORCED要求物化视图数据与基表完全一致；设为TRUSTED或STALE_TOLERATED可放宽限制，但需人工保证数据一致性
SQL 必须满足重写前提，否则优化器直接跳过物化视图
不是所有查基表的 SQL 都能被重写。优化器只在语义等价、可安全替换的前提下才走物化视图——哪怕物化视图结构看起来“够用”，也可能因缺失关键信息被忽略。
- SELECT 列必须能从物化视图中推导出来：比如物化视图只有
SUM(sales)，但 SQL 查AVG(sales)，就不会重写 - WHERE 条件不能引入物化视图里没有的列或表达式，例如物化视图没包含
order_date，SQL 却写了WHERE order_date > SYSDATE-7，重写失败 - 连接条件必须覆盖原查询的关联逻辑；单表物化视图无法支撑多表 JOIN 查询的重写
- 用
EXPLAIN PLAN FOR ...+SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);查看执行计划，确认是否出现MATERIALIZED VIEW REWRITE或访问的是MV_NAME而非基表
常见错误：明明开了重写，执行计划却还是扫基表
最常踩的坑不是配置漏了，而是物化视图状态不合法或统计信息缺失，导致优化器主动弃用它。
- 物化视图状态为
BUILDING、FAILED或NEVER REFRESHED时，优化器默认不考虑它；查USER_MVIEWS确认STALENESS是NOT STALE或STALE（取决于QUERY_REWRITE_INTEGRITY设置） - 物化视图缺少统计信息：
DBMS_STATS.GATHER_TABLE_STATS对 MV 对象本身也要执行一次，否则优化器可能因成本估算失真而放弃重写 - 用户权限不足：需要
QUERY REWRITE系统权限，以及对物化视图的SELECT权限；如果用的是其他 schema 下的 MV，还得有GLOBAL QUERY REWRITE - SQL 中用了绑定变量且类型不明确（如
:b1未指定 NUMBER/VARCHAR2），可能导致重写判定失败；可尝试加类型提示TO_NUMBER(:b1)
刷新策略和重写能力是两回事，别混淆
物化视图能不能被重写，跟它是 ON COMMIT 还是 ON DEMAND 刷新完全无关。只要状态合法、语义匹配、开关全开，哪怕它三天没刷，只要 QUERY_REWRITE_INTEGRITY 设为 STALE_TOLERATED，照样能重写。
-
ON COMMIT只影响数据新鲜度，不提升重写概率；反而因频繁刷新可能拖慢 DML 性能 - 真正影响重写的，是
STALENESS字段值和QUERY_REWRITE_INTEGRITY的组合；比如STALE+ENFORCED= 绝对不重写 - 测试时别只看 DDL 是否成功，务必跑一遍真实 SQL +
EXPLAIN PLAN，否则很容易误以为“已经好了”
重写是否生效，最终只取决于执行计划里那一行访问路径——其它所有配置都是为这一行服务的。很多人调了半天参数，却忘了看 DBMS_XPLAN 输出里有没有真正落到物化视图上。
