物化视图能否有效缓解报表查询压力？Oracle 19c 关键要点
答案是肯定的，但前提是物化视图被正确刷新，并且查询重写功能已启用。在 Oracle 19c 中，默认情况下 query_rewrite_enabled 参数为关闭状态，这意味着即使创建了物化视图，执行类似 select count(*) from sales 的查询时，优化器仍然会扫描原表。此时用户感受到的“加速”效果，实际上是一种错觉。
必须确认两个关键点：第一，物化视图中确实包含数据，而非空表；第二，优化器实际使用了该物化视图——可以通过查询 V$SQL_PLAN 检查执行计划中是否出现 MAT_VIEW ACCESS 字样。两者缺一不可，否则报表查询的性能压力不会得到改善。
如何设置快速刷新（FAST REFRESH）以避免全量重建？
在频繁执行 DML 操作的业务表上，如果使用 COMPLETE 方式刷新，相当于每小时锁表一次，持续数分钟。这不仅无法提升报表性能，反而会导致系统更卡。要使用 FAST 增量刷新，必须满足以下硬性条件：
- 基表必须具备主键或
ROWID，并且已启用FORCE LOGGING。 - 物化视图的定义中必须包含所有基表的
ROWID，常见写法如SELECT sales.*, ROWID FROM sales。 - 必须先创建物化视图日志，示例：
CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE (amount, region) INCLUDING NEW VALUES;。 - 刷新方式必须明确指定为
ON COMMIT，或调用DBMS_MVIEW.REFRESH('mv_sales_daily', 'F')，其中'F'代表fast增量刷新。
上述条件缺一不可，否则快速刷新将无法生效。
为什么报表 SQL 未使用物化视图？常见拦截点分析
即使物化视图已创建并刷新了数据，优化器也不一定会自动使用它。以下是几个最常见的阻碍因素：
- 会话级参数被关闭： 执行了
ALTER SESSION SET QUERY_REWRITE_ENABLED = FALSE;。可通过SELECT * FROM V$PARAMETER WHERE NAME = 'query_rewrite_enabled';检查当前会话状态。 - 物化视图未显式启用查询重写： 创建视图后，必须手动执行
ALTER MATERIALIZED VIEW mv_sales_daily ENABLE QUERY REWRITE;，否则优化器无法识别其替代原表的功能。 - 查询条件与视图定义不匹配： 例如，原表中使用了
TO_CHAR(order_date, 'YYYYMM')这类函数调用，而物化视图仅存储了原始order_date列。此时查询语句中的函数调用与视图列不在同一层级，优化器自然无法使用该视图。 - 统计信息过于陈旧： 需要使用
DBMS_STATS.GATHER_TABLE_STATS同时收集基表和物化视图的统计信息。若统计信息滞后，优化器可能误判成本，认为扫描原表更高效。
高并发场景下物化视图自身成为瓶颈如何解决？
当数百个报表进程同时查询同一物化视图时，I/O 和 buffer cache 的争用可能比直接查询原表更为严重。这并非物化视图设计思路有误，而是缺乏分层策略。
- 按时间粒度拆分： 例如，创建
mv_sales_hourly用于实时看板，同时创建mv_sales_daily用于日结报表。将不同粒度的查询请求分散到多个视图，避免所有压力集中在一张表上。 - 尝试使用
RESULT_CACHE提示： 在 Oracle 19c 兼容模式下，可在查询中添加SELECT /*+ RESULT_CACHE */ SUM(amount) FROM mv_sales_daily WHERE dt = TRUNC(SYSDATE);。该提示可使结果缓存生效，但需注意仅适用于特定场景。 - 使用轻量级权限： 对于只读报表用户，授予
READ权限而非SELECT权限。这是 Oracle 19c 引入的新特性，可减少不必要的解析开销。
还有一个容易被忽略的细节——物化视图的存储参数。默认的 PCTFREE 10 对于只读的统计表而言完全是浪费。建议将此类表设置为 PCTFREE 0，并执行 ALTER TABLE mv_sales_daily MOVE COMPRESS BASIC;。压缩后，扫描的块数将显著减少，缓存效率也会得到直观提升。
