Oracle中的实体化视图（Materialized View）与普通视图不一样，它不仅保存查询定义，还实际存储查询结果集。正因为有物理存储，实体化视图可以像普通表一样参与连接、建立索引、进行分区，也可以直接通过SQL与业务表做联合查询。当系统需要在海量交易明细上反复执行聚合计算时，把汇总结果提前落到实体化视图，再与实时性要求更高的表做关联，通常能明显降低I/O和CPU消耗。
联合使用实体化视图与普通表的本质，是让预计算数据承担复杂聚合，让普通表提供最新明细或补充维度。这种模式在报表系统、数据仓库和BI接口中很常见。下面分别从典型场景、查询重写机制、刷新策略和优化注意点几个方面展开。
实体化视图与普通表联合的典型场景
第一种场景是汇总结果与明细表关联。比如订单表orders每天有上千万行记录，业务上经常需要按地区、产品统计销售额。可以先创建一个按月汇总的实体化视图，保存每个地区每个产品的销售金额与订单数，然后业务查询把这个汇总视图和仅存放当天新增数据的订单表做连接，得到包含最新订单的统计结果。这样历史数据来自实体化视图，当天数据来自普通表，避免全量扫描所有历史订单。
第二种场景是预聚合结果与维度表补充属性。实体化视图里通常只放维度外键和度量值，查询时需要显示产品名称、类目、地区名称等字段，这时直接与产品表、地区表等维度表进行连接。由于维度表一般较小，连接成本不高，实体化视图又过滤掉了明细级的大数据量，整体执行时间可以显著缩短。第三种场景是跨库或远程表物化后与本地表关联。通过数据库链接访问远程表时，如果每次查询都直接远程关联，网络延迟和数据传输会成为瓶颈。可以先将远程表的关键统计结果以实体化视图方式落地到本地，再与本地表做联合查询，减少跨库访问次数。
这些场景的共同点都是：实体化视图负责稳定的大批量聚合，普通表负责实时更新或补充少量字段。设计时要清楚哪些数据可以容忍延迟，哪些数据必须保持最新，再决定连接方向和数据粒度。
联合查询中的查询重写与执行计划
Oracle的查询重写（Query Rewrite）机制允许优化器自动改写原本针对明细表的聚合查询，转向读取实体化视图。例如应用中有一条SQL直接对orders大表按地区做SUM，如果存在结构匹配的实体化视图，优化器有可能直接访问视图数据，而不是重新扫描明细表。要使查询重写生效，需要满足几个条件：实体化视图在创建时启用ENABLE QUERY REWRITE，数据库参数query_rewrite_enabled为true，相关表上有准确的统计信息，底层表与视图的聚合逻辑能够对应。
下面是一个简单的创建与联合查询示例。先创建按月汇总的实体化视图，再与产品表联合查询：
CREATE MATERIALIZED VIEW mv_month_sales
ENABLE QUERY REWRITE
AS
SELECT region_id,
product_id,
SUM(amount) AS total_amount,
COUNT(*) AS order_count
FROM orders
GROUP BY region_id, product_id;
业务查询可以直接把mv_month_sales当作表使用，再关联products表补充产品名称：
SELECT p.product_name,
m.region_id,
m.total_amount,
m.order_count
FROM mv_month_sales m
JOIN products p
ON m.product_id = p.product_id
WHERE p.category_id = 10;
如果应用原本写的是对orders明细表的聚合查询，也可以观察执行计划确认是否被重写。执行计划中如果出现MAT_VIEW ACCESS FULL或MAT_VIEW REWRITE ACCESS，说明查询重写已命中实体化视图。可以使用DBMS_MVIEW包验证实体化视图是否具备重写能力：
EXEC DBMS_MVIEW.EXPLAIN_REWRITE(
query => 'SELECT p.product_name, SUM(o.amount)
FROM orders o, products p
WHERE o.product_id = p.product_id
GROUP BY p.product_name',
mv => 'MV_MONTH_SALES');
需要注意的是，查询重写并非绝对可靠。如果SQL中有复杂表达式、集合操作、非标准连接方式，或者实体化视图没有对应的维度约束，优化器可能放弃重写。此时可以在会话级别使用提示强制走视图，例如使用/*+ REWRITE(mv_month_sales) */提示，但更推荐先通过数据模型和约束保证重写稳定性。
刷新策略影响联合查询的数据一致性
实体化视图的数据新鲜程度由刷新策略决定。完全刷新会在每次刷新时重新执行视图定义里的查询，数据准确但代价高；快速刷新则依赖实体化视图日志，只应用自上次刷新以来的增量变化，适合大表汇总。如果在联合查询中把实体化视图看作几乎实时的数据源，就应当选择快速刷新，并尽量缩短刷新间隔。否则实体化视图可能与普通表数据不一致，例如当天订单已经写入表，但汇总视图尚未包含这些订单。
创建支持快速刷新的实体化视图时，底层表需要建立物化视图日志，并且聚合逻辑需要符合快速刷新的限制条件。示例：
CREATE MATERIALIZED VIEW LOG ON orders
WITH SEQUENCE, ROWID, PRIMARY KEY
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW mv_daily_sales
REFRESH FAST ON DEMAND
ENABLE QUERY REWRITE
AS
SELECT region_id,
product_id,
SUM(amount) AS total_amount,
COUNT(*) AS order_count
FROM orders
GROUP BY region_id, product_id;
如果业务允许小时级或天级延迟，可以采用定时任务在低峰期刷新，既能控制系统负载，又能保证绝大多数查询结果稳定。对于实时性要求特别高的场景，则不建议把实体化视图当作唯一数据源，而应结合普通表进行补偿，例如只对历史分区建实体化视图，当前分区直接查表并用UNION ALL合并。
联合查询的性能优化与维护注意事项
实体化视图与普通表联合查询时，连接条件的索引设计非常关键。实体化视图虽然有物理存储，但不会自动在连接列上创建索引。对于较大的视图，最好在region_id、product_id等关联字段上建立组合索引，避免优化器选择全表扫描后哈希连接造成额外开销。普通表一端也要检查外键列是否有索引，否则连接时可能出现不必要的全表扫描或锁等待。
统计信息同样重要。实体化视图的数据分布与底层表不一定一致，因此单独收集实体化视图的统计信息有助于优化器判断连接基数和成本。可以使用DBMS_STATS.GATHER_TABLE_STATS对视图和普通表分别收集。另外，如果实体化视图数据量很大，可以考虑按时间或区域进行分区，把大连接转化为分区内连接，同时利用分区裁剪减少读取量。
维护方面还要关注物化视图日志的大小和清理。频繁的DML会导致日志快速增长，如果刷新间隔过长，日志会占用大量空间，也可能影响快速刷新速度。通过定期刷新和监控DBA_MVIEWS、DBA_MVIEW_LOGS等数据字典视图，可以及时发现失效或状态异常的对象。总体来看，实体化视图与表联合使用并不是简单的表替换，而是一个涉及建模、刷新、索引和查询重写的组合优化过程，需要结合具体业务访问模式反复调整。
Oracle实体化视图表连接查询查询重写修改时间：2026-08-28 07:41:50