物化视图查询爆内存的根源是分区裁剪失效或实时计算未触发，导致全分区扫描及大量排序/聚合；关键在于分区键必须同时出现在基表分区定义、MV SELECT列、MV日志及查询WHERE中。
物化视图本身不占内存，真正吃内存的是查询执行时的临时区（temp）和 pga，根源通常是分区裁剪失效或实时计算未触发——导致全分区扫描+大量排序/聚合。
为什么物化视图查询会爆内存（ORA-04030 / ORA-1555）
常见错误现象：ORA-04030: out of process memory 或执行计划中出现 TEMP TABLE TRANSFORMATION + SORT AGGREGATE；V$SQL_WORKAREA 显示大量 ONEPASS 或 MULTIPASS 操作。
- 分区键未出现在物化视图 SELECT 列中 → 优化器无法推导裁剪条件，哪怕 WHERE 里写了分区列也无效
- 物化视图日志缺失分区键列 →
ON QUERY COMPUTATION不生效，查询被迫走基表全量扫描 - 物化视图定义含非确定性函数（如
SYSDATE、ROWNUM）、子查询或外连接 → 禁用实时计算，且可能禁用查询重写 - 基表分区策略与物化视图不一致（如基表按
CREATED_DATERANGE 分区，但物化视图按STATUSLIST 分区）→ 分区裁剪完全失效
如何验证是否真在用物化视图（而非回退到基表）
别只看 EXPLAIN PLAN 里有没有物化视图名——重点看访问路径和分区信息：
- 执行
EXPLAIN PLAN FOR SELECT ... FROM your_mv;后查SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); - 确认输出中存在
PARTITION LIST SINGLE或PARTITION RANGE ITERATOR，且PSTART/PSTOP是具体数字（如 3,3），不是 1,4 - 若看到
TABLE ACCESS FULL对应的是基表名（如T1）而非物化视图名（如MV_SALES），说明查询重写失败 - 检查
SELECT mview_name, rewrite_enabled, refresh_mode, build_mode FROM user_mviews;中rewrite_enabled = 'Y'且refresh_mode IN ('DEMAND', 'COMMIT')
精简物化视图定义的关键操作
目标是让优化器敢用、能裁剪、可实时计算：
- 确保 SELECT 列显式包含所有基表分区键（如基表按
TRUNC(CREATED_DATE, 'MM')分区，则 MV 定义里必须有该表达式或原始列） - 避免在 MV 定义中使用
SELECT *—— 改为明确列出字段，尤其要排除BLOB、CLOB等大对象列（它们会强制 PGA 增长） - 聚合类 MV 尽量用简单 GROUP BY，不用嵌套子查询；若需过滤，优先在基表加 WHERE 条件（如
WHERE status = 'ACTIVE'），而非在 MV 外层加 - 创建物化视图日志时必须带分区键：例如
CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE(trunc(created_date,'MM')) INCLUDING NEW VALUES; - 对已有 MV，先
ALTER MATERIALIZED VIEW mv_name DISABLE QUERY REWRITE;，再ENABLE，强制刷新元数据缓存
容易被忽略的隐含参数与权限陷阱
即使语法全对，也可能因底层开关没开而白忙：
- 检查
SELECT value FROM v$parameter WHERE name = '_mview_refresh_use_query_computation';—— 必须为TRUE（默认开启，但某些 12.1.0.2 补丁后版本会重置为 FALSE） -
QUERY_REWRITE_ENABLED=TRUE需在 session 或 system 级设置，不能只靠 MV 自身属性 - 用户执行查询的 schema 必须有
QUERY REWRITE系统权限，或对物化视图有SELECT+QUERY REWRITE对象权限 -
staleness='STALE'时，即使开了实时计算，Oracle 也会跳过重写 —— 手动执行EXEC DBMS_MVIEW.REFRESH('MV_NAME');再试
最常出问题的地方不在定义多复杂，而在分区键是否“露脸”：它得同时出现在基表分区定义、物化视图 SELECT 列、物化视图日志、以及查询 WHERE 条件里——缺一不可。少一个，就退回全表扫。
