物化视图本身不能分区，因为Oracle不允许在CREATE MATERIALIZED VIEW中指定PARTITION BY子句，其为逻辑对象，物理存储由系统自动管理，始终是单个段，USER_TAB_PARTITIONS查不到分区信息。
不能直接对含聚合的物化视图做分区维护，它本身不支持分区，但可通过基表分区 + PCT 刷新间接实现按分区粒度维护
为什么物化视图本身不能分区？
Oracle 不允许在 CREATE MATERIALIZED VIEW 语句中指定 PARTITION BY 子句；物化视图是逻辑对象，其物理存储由系统自动管理，不暴露分区接口。即使基表是 range 分区表，物化视图本身仍是单个段（segment），USER_TAB_PARTITIONS 查不到它的分区信息。
常见误操作：试图对物化视图执行 ALTER MATERIALIZED VIEW ... SPLIT PARTITION 或查询 DBA_MVIEWS 中的 PARTITIONED 字段——该字段恒为 NO，无实际意义。
PCT 刷新是唯一可行的“分区级维护”路径
当物化视图定义中含 SUM、COUNT、AVG 等聚合函数时，仍可启用 PCT（Partition Change Tracking）快速刷新，前提是满足全部硬性条件：
- 基表必须是
RANGE或LIST分区（HASH或COMPOSITE不支持 PCT） - 分区键只能是单个列（如
LOG_DATE），且该列必须出现在物化视图的SELECT列表和GROUP BY子句中 - 物化视图定义中不能含
ROWNUM、SYSDATE、子查询、连接（JOIN）、分析函数或非确定性表达式 - 建物化视图前，需确保基表已启用
ENABLE ROW MOVEMENT，并执行DBMS_MVIEW.EXPLAIN_MVIEW验证是否支持 PCT
验证示例：EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_SALES_DAILY');
查 MVIEW_EXCEPTIONS 表，若 capability_name = 'PCT' 且 possible = 'Y'，才真正可用。
日常维护中如何“按分区”触发刷新？
PCT 刷新不依赖物化视图日志（MLOG$），而是靠 Oracle 自动识别基表中哪些分区被 DML 修改过。因此，维护动作本质是「让 Oracle 知道只刷哪几个分区」：
- 确保每次 ETL 只加载/修改一个日期分区（如
ALTER TABLE sales EXCHANGE PARTITION p_202406 WITH TABLE sales_stg） - 刷新时不传全量参数，改用
DBMS_MVIEW.REFRESH的list指定物化视图名，并设method => 'F'（快速）和atomic_refresh => FALSE（避免锁整个 MV） - 关键点：刷新前执行
DBMS_STATS.GATHER_TABLE_STATS更新基表分区统计信息，否则 Oracle 可能误判变更范围，退化为全表扫描 - 不要手动清理物化视图日志（
DBMS_MVIEW.PURGE_LOG）——PCT 模式下日志压根没被使用
典型调用：DBMS_MVIEW.REFRESH(list => 'MV_SALES_DAILY', method => 'F', atomic_refresh => FALSE);
容易忽略的兼容性陷阱
PCT 对 Oracle 版本和功能依赖极强：
- 9i 引入，但直到 12c 才稳定支持含
COUNT(*)的 PCT；11g 中若物化视图含COUNT(column)且该列允许 NULL，PCT 刷新可能漏数据 - 如果基表用了
INMEMORY或COMPRESS FOR QUERY，PCT 刷新可能失败，需临时禁用压缩再刷新 - 物化视图定义中若引用了其他物化视图（嵌套 MV），PCT 不生效，会强制降级为完全刷新
-
QUERY_REWRITE_ENABLED=TRUE和QUERY_REWRITE_INTEGRITY=STALE_TOLERATED必须同时设置，否则优化器可能拒绝重写到该 MV，使 PCT 维护失去业务价值
最隐蔽的问题：分区键字段类型为 DATE 时，基表分区边界若用 TO_DATE('2024-07-01','YYYY-MM-DD') 定义，而物化视图 SQL 中写成 TRUNC(log_date)，会导致 PCT 机制失效——Oracle 要求分区键表达式完全一致。
