当前位置：首页 > 数据库 > Oracle教程 > oracle优化利器之 物化视图 > 正文

oracle优化利器之 物化视图

来源：这里教程网 时间：2026-03-03 22:05:44 作者：

Oracle 19c 中的物化视图是一种强大的数据库对象，它 存储了查询结果的物理副本，并可以定期或根据特定条件刷新以保持与基础数据的相对同步。它与普通视图（仅存储查询定义）的关键区别在于它实际存储了数据，从而显著提高复杂查询的性能，尤其是在数据仓库和报表场景中。

以下是 Oracle 19c 物化视图的核心概念、特性和管理要点：

一、 核心概念与目的：

物理存储数据： 将  SELECT 语句的结果集持久化地存储在数据库表段中。

  • 性能提升： 对复杂、聚合或涉及大表连接的查询，直接查询预计算好的物化视图比执行原始查询快得多。

  • 数据复制/分发： 常用于跨数据库（如主库到备库、中心到分支）复制和同步数据子集。

  • 查询重写： Oracle 优化器能自动将针对基表的查询重写为使用已存在的物化视图（如果更高效且启用了此功能）。

  • 减少网络负载： 在分布式系统中，本地物化视图可以减少远程查询。

    1. 关键特性：

      刷新机制： 这是物化视图的核心管理点。Oracle 19c 支持：

      COMPLETE： 完全刷新。删除物化视图中所有数据，重新执行定义查询。简单可靠，但大数据量时资源消耗大、耗时长。

    2. FAST： 快速刷新（增量刷新）。仅应用自上次刷新以来基表发生的更改（通过物化视图日志实现）。高效，但需要额外维护日志且仅支持特定查询类型（通常涉及聚合或连接）。

    3. FORCE： 默认选项。Oracle 尝试使用  FAST 刷新；如果  FAST 不可用，则回退到  COMPLETE。

    4. ON COMMIT： 在基表的事务提交时 自动进行  FAST 刷新。确保物化视图与基表高度实时同步，但会增加基表事务的开销。

    5. ON DEMAND： 需要 手动调用  DBMS_MVIEW.REFRESH 或通过调度任务（DBMS_SCHEDULER/DBMS_JOB）刷新。提供最大的刷新控制。

    6. 物化视图日志： 对于支持  FAST 刷新的物化视图，必须在基表上创建物化视图日志。该日志记录基表上发生的 DML 操作（INSERT, UPDATE, DELETE），供快速刷新过程使用。

    7. 查询重写：

      启用 ( ENABLE QUERY REWRITE) 后，优化器在满足条件时会透明地将针对基表的查询重写为使用物化视图。

    8. 需要  QUERY REWRITE 权限和合适的初始化参数设置 ( QUERY_REWRITE_ENABLED = TRUE,  QUERY_REWRITE_INTEGRITY 设置信任级别)。

    9. 构建方式：

      IMMEDIATE： 创建物化视图时立即执行定义查询并填充数据。

    10. DEFERRED： 创建时为空的物化视图，后续需要手动刷新才能填充数据。

    11. 预建表： 允许使用现有表作为物化视图的存储容器。

    12. 分区物化视图： 物化视图本身可以分区，提高管理性和查询性能。

    13. 实时物化视图： Oracle 12c 引入并在后续版本增强的特性。物化视图包含一个“陈旧”部分（上次刷新后的数据）和一个“实时”部分（通过联机重写直接访问基表的最新数据）。查询时自动结合这两部分，提供近乎实时的结果，而无需频繁的  ON COMMIT 刷新。在 19c 中此功能已相当成熟。

      二、创建基本语法：

      CREATE MATERIALIZED VIEW [schema.]mv_name[BUILD {IMMEDIATE | DEFERRED}][REFRESH [FAST | COMPLETE | FORCE]
 [ON DEMAND | ON COMMIT]
 [START WITH start_time] [NEXT next_interval]
 [WITH {PRIMARY KEY | ROWID}]
 [USING {DEFAULT | <rollback_segment>} ...][ENABLE | DISABLE] QUERY REWRITEAS<select_statement>;

      三、管理与维护：

      手动刷新：

      EXEC DBMS_MVIEW.REFRESH('mv_name', method => 'F'); -- 'F' for FAST, 'C' for COMPLETEEXEC DBMS_MVIEW.REFRESH('mv_name, mv_name2', method => 'C'); -- Refresh multiple

    14. 自动刷新： 使用  DBMS_SCHEDULER 或  DBMS_JOB 创建定时任务调用  DBMS_MVIEW.REFRESH。

    15. 监控：

      视图  USER_MVIEWS /  ALL_MVIEWS /  DBA_MVIEWS：物化视图定义、刷新状态、最后刷新时间等。

    16. 视图  USER_MVIEW_REFRESH_TIMES：上次刷新时间戳。

    17. 视图  USER_MVIEW_LOGS /  DBA_MVIEW_LOGS：物化视图日志信息。

    18. 视图  USER_REFRESH_DEPENDENCIES：物化视图的依赖关系。

    19. 修改： 使用  ALTER MATERIALIZED VIEW 命令修改刷新方式、启用/禁用查询重写等（不能直接修改查询定义，通常需要重建）。

    20. 删除：  DROP MATERIALIZED VIEW mv_name; （物化视图日志需要单独删除）。

    四、使用场景  4.1、性能优化场景（数据仓库与报表）

    核心价值：预计算复杂查询，减少实时计算压力。

      电信业务初始化数据加载

      问题：进程启动需从4个表关联查询全球运营商数据（networkid、cc、ndc等），频繁访问导致性能瓶颈。

    1. 解决方案：创建 ON COMMIT刷新的物化视图，将多表连接结果物化。基表DML提交后自动刷新视图，业务进程直接查询物化视图，响应时间从秒级降至毫秒级。

    2. 技术要点：

      CREATE MATERIALIZED VIEW IRDB_NETWORKLIST
REFRESH FORCE ON COMMIT  -- 提交时强制刷新（优先尝试FAST增量）AS SELECT ... FROM tableA, tableB, tableC ...;  -- 复杂关联查询

    3. 电商销售日报分析

      问题：每日统计大表（亿级订单）的销售额、地区排行等聚合查询耗时过长。

    4. 解决方案：创建按日分组的物化视图，定时全量刷新（如凌晨）。报表查询直接访问物化视图，性能提升10倍以上 6。

    5. 技术要点：结合 REFRESH COMPLETE ON DEMAND + DBMS_SCHEDULER定时任务。

    4.2、数据同步与分布式场景

    核心价值：跨节点部分数据复制，降低网络负载。

      移动彩铃业务的多节点同步

      需求：管理节点需向5个呼叫节点同步用户表（ T_USERINFO）的部分字段（如手机号、品牌ID）。

    1. 解决方案：

      呼叫节点创建FAST刷新物化视图，仅同步必要列：

      CREATE MATERIALIZED VIEW T_USERINFO_MV
REFRESH FAST WITH PRIMARY KEY  -- 基于主键增量同步AS SELECT phonenumber, localid, brandid FROM T_USERINFO@dblink_admin;

    2. 通过 DBMS_REFRESH组每10秒批量刷新。

    3. 效果：避免全库同步（如DG），仅传输增量变更，网络开销降低70%。

    4. 跨国企业区域数据本地化

      问题：亚太区频繁查询欧美数据库的订单表，网络延迟高。

    5. 方案：在亚太数据库创建物化视图，按需刷新（如每小时），将远程数据本地化存储。

    4.3、实时数据接入场景

    核心价值：近实时数据整合，替代ETL批处理。

      实时物化视图（12c+特性增强）

      案例：风险监控系统需即时统计交易流水。

    1. 方案：

      CREATE MATERIALIZED VIEW risk_trans_summary
REFRESH FAST ON COMMIT  -- 事务提交时增量刷新AS SELECT user_id, SUM(amount) FROM transactions GROUP BY user_id;

    2. 效果：基表提交后200ms内视图更新，查询直接命中聚合结果。

    3. 流式数据预处理

      物联网设备日志按 ROWID创建物化视图日志，FAST刷新过滤异常数据，供实时告警使用。

    五、技术选型与最佳实践

      刷新方式对比

      刷新类型 适用场景 前提条件 性能影响
      ON COMMIT 秒级延迟场景 基表需创建物化视图日志 事务提交时额外开销
      FAST 大表增量同步 必须建日志，且查询符合快速刷新约束 低开销，依赖日志量
      COMPLETE 小表/无日志场景 无要求 全量重建，资源消耗大
      ON DEMAND 允许延迟的批处理 可搭配定时任务 可控的异步刷新

    1. 物化视图日志设计原则

      主键 vs ROWID：

      主键日志：需基表有主键，支持多表连接视图。

    2. ROWID日志：单表简单聚合，不支持连接（因连接后行标识丢失）。

    3. 日志优化：定期清理高水位线，对 MLOG$_表建索引避免全表扫描。

      建议：

    延迟敏感且基表事务频繁 →  ON COMMIT + 主键日志

  • 海量数据跨库同步 →  FAST +  ON DEMAND定时任务

  • 历史数据分析 →  COMPLETE刷新 + 列存储压缩

    • 通过物化视图，可在性能、实时性、资源开销间取得平衡，是Oracle数据架构优化的利器

    • 编辑推荐：

    相关推荐

    最新软件资讯

    Oracle高级技术——CTE
    Oracle高级技术——CTE

    热文推荐

    天极热推