物化视图不会自动加速多表关联报表，必须显式改SQL、建索引、配权限并开启重写开关；否则EXPLAIN PLAN中不会显示其被使用。
物化视图不能自动加速多表关联报表——必须显式改SQL、建对索引、配齐权限和重写开关，否则EXPLAIN PLAN里永远看不到它。
为什么EXPLAIN PLAN不显示物化视图被使用？
这不是优化器“没选对”，而是根本没进候选池。常见原因有四个：
-
QUERY_REWRITE_ENABLED是'FALSE'：查V$PARAMETER确认值，连接池复用后会话级设置不生效，生产环境必须全局开或在应用层初始化 SQL 中加ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE - MV 缺
ENABLE QUERY REWRITE子句：已有 MV 无法通过ALTER补，只能DROP后重建 - 基表没主键或没显式包含
ROWID：建 MV 时若含聚合或连接，必须确保所有基表有主键，否则报ORA-30353 - 查询语义不匹配：比如 MV 存的是
sale_date，你查TRUNC(sale_date, 'MM')或TO_CHAR(sale_date, 'YYYY-MM')，优化器直接判定不等价
验证是否真能重写，别看 EXPLAIN PLAN，跑这个：
EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT region, SUM(amount) FROM sales JOIN customers USING(cust_id) WHERE sale_date >= DATE ''2024-01-01'' GROUP BY region', 'MV_SALES_REGION_SUM');
查 REWRITE_TABLE 的 REWRITE_MECHANISM 字段：只有 TEXT_MATCH 或 GENERAL 才算成功。
多表JOIN+GROUP BY的MV怎么建才支持FAST REFRESH ON COMMIT？
不是所有多表聚合都能快速刷新。要支持 ON COMMIT FAST，必须同时满足：
- 所有参与表都建了物化视图日志，且日志带
ROWID、SEQUENCE和INCLUDING NEW VALUES，例如：CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE(sale_id, cust_id, sale_date) INCLUDING NEW VALUES - MV 定义中
SELECT列必须包含全部GROUP BY字段，且必须含COUNT(*)（哪怕你不需要） - 只允许标准聚集函数：
SUM、COUNT、AVG、MIN、MAX，不能用LISTAGG或自定义函数 - 连接字段必须是等值连接，不能有
<>、IS NULL或函数包裹（如UPPER(name)）
漏一条，REFRESH FAST ON COMMIT 就会失败，降级为 COMPLETE 或报错。
建完MV为什么报表还是慢？
MV 是张物理表，Oracle 不会自动给它建索引。没索引的 MV 在 WHERE 过滤或 ORDER BY 时照样全表扫描：
- 立即建复合索引，顺序按高频访问模式排：等值过滤字段放前（如
region），范围字段放后（如sale_date）：CREATE INDEX idx_mv_reg_dt ON mv_sales_region_sum (region, sale_date) - 如果报表常按时间分页，考虑在 MV 上分区：
PARTITION BY RANGE(sale_date)，配合DBMS_MVIEW.REFRESH_FAST_AFTER_INSERT按分区刷 - 别依赖基表索引——MV 的索引必须单独建，且字段名、类型、顺序必须和 MV 定义严格一致
另外，Spring Boot + MyBatis 的参数化 SQL 若含动态 IN 或 OR 条件，可能破坏语义匹配，导致重写失效；这种场景建议用固定结构 SQL + MV，再由应用层做二次过滤。
跨库（DB Link）关联根本不能靠物化视图自动优化
只要 SQL 里出现 @remote_db，优化器连尝试重写的动作都不会做：DBMS_MVIEW.EXPLAIN_REWRITE 直接返回 REWRITE_CANNOT_BE_USED，EXPLAIN PLAN 中必见 REMOTE 操作符。
真想提速，只有三步闭环：
- 把远程表关键数据落地为本地表（注意 CLOB/BLOB 同步完整性、分区策略对齐）
- 在该本地表上建 MV，并加
ENABLE QUERY REWRITE - 手动修改报表 SQL，把
FROM sales@remote_db替成FROM mv_sales_local——没有“自动替代”，只有“显式引用”
最容易被忽略的是第三步：很多人建完 MV 就以为万事大吉，结果 BI 工具仍在发带 @ 的原始 SQL，MV 彻底闲置。
