要实现复合分区表上物化视图的分区修剪，关键在于MV结构与基表分区键完全对齐：SELECT列表必须包含原始time_id和region列，日志需含分区键并启用INCLUDING NEW VALUES，ON PREBUILT TABLE时须手动分区，查询WHERE条件须直连原始列且MV状态不能为STALE。
复合分区表上物化视图要真正实现分区修剪，关键不在“建了MV”，而在“MV结构与基表分区逻辑对齐”。否则即使基表按 TIME_ID 范围 + REGION 列表复合分区，物化视图查询仍可能全表扫描。
物化视图定义必须显式包含所有分区键列
Oracle优化器无法从函数、表达式或缺失列中推导分区裁剪条件。哪怕基表是 PARTITION BY RANGE (time_id) SUBPARTITION BY LIST (region)，物化视图的 SELECT 列表里也必须原样包含 time_id 和 region 两列——不能只选 TRUNC(time_id, 'MM')，也不能漏掉 region。
- 错误写法：
SELECT id, cust_name, TRUNC(time_id, 'MM') mth FROM sales→ 丢失原始time_id值，无法匹配分区边界 - 正确写法：
SELECT id, cust_name, time_id, region FROM sales→ 保留原始分区键，WHERE 条件可直接下推 - 若业务真不需要原始值，可在物化视图上额外建函数索引，但修剪仍依赖基础列存在
物化视图日志需覆盖分区键且启用 INCLUDING NEW VALUES
FAST刷新依赖日志记录变更细节。复合分区表本身不自动提供子分区键变更捕获能力，必须人工确保日志包含所有分区键列，并启用新值记录。
- 必须执行：
CREATE MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY, ROWID, SEQUENCE(time_id, region) INCLUDING NEW VALUES - 漏掉
region：子分区更新时日志无记录，FAST刷新失败，报ORA-12052 - 缺
INCLUDING NEW VALUES：UPDATE 操作只记旧值，无法精确计算增量变化，强制退化为 COMPLETE 刷新 - 日志表空间建议独立，避免与基表争抢 I/O
ON PREBUILT TABLE 场景下，物化视图存储表必须手动分区
物化视图本身不继承基表分区属性。用 ON PREBUILT TABLE 方式创建时，底层物理表默认是普通堆表。若不手动分区，后续所有查询都丧失剪枝能力，哪怕 WHERE 条件完全匹配分区键。
- 先建分区表：
CREATE TABLE mv_sales PARTITION BY RANGE (time_id) SUBPARTITION BY LIST (region) (...) - 再关联物化视图：
CREATE MATERIALIZED VIEW mv_sales ON PREBUILT TABLE AS SELECT ... FROM sales - 验证是否生效：
EXPLAIN PLAN FOR SELECT * FROM mv_sales WHERE time_id >= DATE '2026-01-01' AND region = 'EAST';，执行计划中必须出现PARTITION RANGE ITERATOR或PARTITION LIST SINGLE，且pstart/pstop显示非全范围 - 别忘了在各分区上建本地索引，否则单分区扫描仍可能变慢
查询时 WHERE 条件必须直连 MV 列，不可嵌套或转换
即使物化视图结构完美对齐，查询语句写错也会让剪枝失效。优化器不会逆向推导函数等价性。
- 有效条件：
WHERE time_id BETWEEN DATE '2026-01-01' AND DATE '2026-01-31' AND region = 'WEST' - 无效条件：
WHERE EXTRACT(YEAR FROM time_id) = 2026 AND region IN ('WEST', 'EAST')→EXTRACT阻断剪枝，IN可能导致多个子分区被扫 - 更隐蔽的坑：
WHERE time_id >= TO_DATE('2026-01-01', 'YYYY-MM-DD')看似没问题，但如果time_id是DATE类型而绑定变量传入的是字符串，隐式转换会绕过索引和剪枝 - 用
DBMS_XPLAN.DISPLAY看真实pstart/pstop值，别信“已使用物化视图”这种模糊提示
最易被忽略的一点：物化视图状态为 STALE 时，即使结构全对、查询写法正确，优化器也可能跳过重写而直扫基表——因为陈旧数据不满足一致性要求。每次批量 DML 后，记得确认 staleness 并及时刷新，别只依赖自动机制。
