物化视图查询重写：为什么你的配置没生效？

在数据库性能优化领域，物化视图的查询重写功能堪称一把利器。但不少朋友都遇到过这样的困惑：明明按照文档一步步配置了，为什么执行计划还是雷打不动地扫描基表？问题往往出在几个容易被忽略的细节上。今天，我们就来把这些关键点逐一拆解清楚。

物化视图需同时开启全局QUERY_REWRITE_ENABLED参数和对象级ENABLE QUERY REWRITE，且满足语义等价、状态合法、统计信息完备、权限充足等条件，执行计划中间出现MATERIALIZED VIEW REWRITE才表明重写生效。

物化视图必须显式启用 QUERY REWRITE 才能被自动路由

首先得明确一个前提：Oracle数据库默认是关闭查询重写功能的。这意味着，即便你创建了物化视图，甚至加上了enable query rewrite子句，优化器也不会自动把查询路由过去——除非你把全局和对象级的两道“开关”都打开。

• 全局开关：通过ALTER SYSTEM SET QUERY_REWRITE_ENABLED = TRUE;来开启。这里还可以设置为FORCE，它会强制重写，甚至忽略掉物化视图本身的禁用设置。
• 对象级开关：创建物化视图时必须显式带上ENABLE QUERY REWRITE。例如：

  CREATE MATERIALIZED VIEW mv_sales_sum
    ENABLE QUERY REWRITE
    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进行一场严格的“资格审查”。不是所有查询基表的SQL都能被重写，优化器只在确认语义完全等价、可以安全替换的前提下，才会选择物化视图。有时候，哪怕物化视图的结构看起来“差不多够用”，也可能因为缺失关键信息而被优化器直接忽略。

• SELECT列表必须可推导：物化视图里有的列或聚合结果，才能被用来重写。比如，物化视图只计算了SUM(sales)，但你的SQL却要查A VG(sales)，那重写就不会发生。
• WHERE条件不能越界：查询条件中引入的列或表达式，必须在物化视图中存在。例如，物化视图没包含order_date列，而你的SQL写了WHERE order_date > SYSDATE-7，重写同样会失败。
• 连接逻辑必须覆盖：多表关联查询的重写，要求物化视图必须完整覆盖原查询的JOIN逻辑。一个单表的物化视图，显然无法支撑多表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，优化器就可能因为成本估算失真，认为扫描基表更划算，从而放弃重写。
• 权限不足：用户需要拥有QUERY REWRITE系统权限，以及对物化视图的SELECT权限。如果要使用其他schema下的物化视图，还需要GLOBAL QUERY REWRITE权限。
• 绑定变量类型模糊：SQL中如果使用了未明确类型的绑定变量（如:b1），可能导致重写判定失败。可以尝试为绑定变量添加类型提示，例如TO_NUMBER(:b1)。

刷新策略和重写能力是两回事，别混淆

这里有一个常见的理解误区：很多人以为ON COMMIT（提交时刷新）的物化视图比ON DEMAND（按需刷新）的更容易被重写。其实不然。物化视图能否被重写，与其刷新机制没有直接关系。只要它的状态合法、语义匹配、开关全开，哪怕已经三天没刷新了，只要QUERY_REWRITE_INTEGRITY参数设置为STALE_TOLERATED

• ON COMMIT只影响数据的实时性，并不提升被重写的概率。相反，频繁的刷新还可能拖慢DML操作的性能。
• 真正影响重写决策的，是USER_MVIEWS.STALENESS字段的值与QUERY_REWRITE_INTEGRITY参数的组合。例如，STALE（数据已陈旧）状态加上ENFORCED（强制一致性）的完整性设置，结果就是绝对不重写。
• 因此，测试时绝不能只看DDL语句是否执行成功。务必用真实的业务SQL跑一遍，并结合EXPLAIN PLAN查看执行计划，否则很容易产生“已经配置好了”的错觉。