物化视图不能自动加速报表查询，必须满足结构匹配、QUERY_REWRITE_ENABLED=TRUE且用户有权限、优化器评估成本更低三个条件；EXPLAIN PLAN不显示重写需用DBMS_MVIEW.EXPLAIN_REWRITE验证；多维查询应按高频模式拆分建多个MV；MV需手动创建合适顺序的复合索引，且刷新性能需权衡。
物化视图真能自动加速报表查询吗？
不能自动加速，必须满足三个硬性条件：物化视图结构匹配查询语义、query_rewrite_enabled = true 且用户有 query rewrite 权限、优化器评估后认为走 mv 成本更低。常见现象是建完 mv 后 explain plan 里仍显示访问基表，不是配置漏了，就是语义不匹配。
为什么 EXPLAIN PLAN 看不到 MV REWRITE 行？
这是最常被忽略的诊断盲区。优化器是否启用重写，不能靠猜，必须用 DBMS_MVIEW.EXPLAIN_REWRITE 显式验证：
- 先执行
EXPLAIN REWRITE过程，传入你的报表 SQL 和目标 MV 名 - 查
REWRITE_TABLE（需提前运行UTLXRWY.SQL创建），看REWRITE_MECHANISM字段值：只有TEXT_MATCH或GENERAL才表示成功匹配；UNREWRITTEN或FAILED就得调结构 - 注意：即使 MV 状态为
BUILD IMMEDIATE且REFRESH ON DEMAND，若QUERY_REWRITE_INTEGRITY设为ENFORCED但基表缺 RELY 约束，也会静默失败
多维报表查询该建几个物化视图？
别试图用一个“全能” MV 覆盖所有维度组合。Oracle 查询重写器只匹配单个 MV，不拼接多个结果。正确做法是按高频查询模式拆分：
- 对 “按天+区域+产品线汇总销售额” → 建
mv_sales_daily_region_prod，GROUP BY time_id, region, product_line - 对 “按月大区毛利+同比” → 单独建
mv_profit_monthly_region，避免在 MV 定义里用TO_CHAR(time_id, 'YYYYMM')（会阻断重写），改用TRUNC(time_id, 'MM')或EXTRACT(YEAR FROM time_id)+EXTRACT(MONTH FROM time_id) - 分区表上建 MV 时，
PARTITION BY RANGE (time_id)是可选项，但建议加上——方便后续用DBMS_MVIEW.REFRESH_FAST_AFTER_INSERT按分区增量刷新
物化视图建完就万事大吉？索引才是关键
MV 是一张物理表，但 Oracle 不会自动给它加任何索引。没索引的 MV 在 WHERE 条件过滤时照样全表扫描：
- 立即执行
CREATE INDEX idx_mv_time_region ON mv_sales_daily_region_prod (time_id, region)，而不是等报表慢了再补 - PostgreSQL 的物化视图不支持主键约束，Oracle 虽支持但需显式定义；别依赖基表索引，MV 的索引必须单独建
- 复合索引顺序很重要：高频等值过滤字段放前面（如
region），范围查询字段放后面（如time_id） - 每个额外索引都会拖慢
REFRESH，大 MV 上超过 3 个索引就要权衡——先压测刷新耗时
真正卡住人的往往不是创建语法，而是重写是否生效、索引是否覆盖、以及刷新策略和基表变更节奏是否咬合。这三个点任何一个松动，MV 就退化成一张没人维护的普通表。
