物化视图未走分区裁剪的典型信号是DBMS_MVIEW.EXPLAIN_MVIEW显示QSMQT_UNREWRITE，主因是物化视图与查询间存在语义断层，如分区键表达式不一致、函数包装或类型转换差异；需严格匹配物理分区列及表达式、同步统计信息、避免宽松重写设置，并在必要时手动利用MV分区信息跳转基表分区。
物化视图没走分区裁剪，DBMS_MVIEW.EXPLAIN_MVIEW 显示 QSMQT_UNREWRITE
这是最典型的信号：查询本应重写为物化视图访问，但优化器拒绝了。根本原因常是物化视图定义与查询之间存在「语义断层」——比如物化视图按 trunc(sale_date, 'mm') 分区，而查询用 sale_date >= date '2024-01-01'，oracle 无法证明两者等价。分区键表达式必须严格一致或可推导，函数包装、隐式类型转换、nls 设置差异都会导致裁剪失效。
实操建议：
- 检查物化视图的分区键表达式，用
SELECT PARTITIONING_TYPE, SUBPARTITIONING_TYPE, COLUMN_NAME FROM USER_TAB_PARTITIONS WHERE TABLE_NAME = 'MV_SALES'确认实际分区列名（注意：它显示的是物理列，不是 SELECT 列表里的别名） - 查询中过滤条件必须直接作用于该物理列，且表达式完全匹配。例如物化视图按
TO_CHAR(SALE_DT, 'YYYY-MM')分区，则查询必须写TO_CHAR(SALE_DT, 'YYYY-MM') = '2024-01'，不能用SALE_DT BETWEEN ... - 禁用
QUERY_REWRITE_ENABLED=FALSE或QUERY_REWRITE_INTEGRITY=STALE_TOLERATED这类宽松设置，它们会让重写逻辑绕过分区验证，反而掩盖问题
EXPLAIN PLAN 显示走基表而非物化视图，但 DBMS_MVIEW.EXPLAIN_MVIEW 又说可重写
说明重写逻辑通过了语法和语义校验，但成本估算让它败给了基表扫描。分区表+物化视图双重结构下，CBO 对分区裁剪后物化视图的基数估计常严重失真——尤其当物化视图本身未分析，或基表统计信息陈旧时。
实操建议：
- 对物化视图执行
DBMS_STATS.GATHER_TABLE_STATS，且显式指定GRANULARITY => 'ALL'，确保分区级统计被采集（默认可能只扫全局） - 确认基表和物化视图的统计信息时间戳是否同步：
SELECT TABLE_NAME, STALE_STATS, LAST_ANALYZED FROM USER_TAB_STATISTICS WHERE TABLE_NAME IN ('SALES', 'MV_SALES') - 临时加 hint 测试：在查询中嵌入
/*+ REWRITE(MV_SALES) */，若执行计划立刻切到 MV 且性能提升，就坐实是 CBO 成本误判
物化视图含聚合，但查询只取明细，仍想命中分区
Oracle 的查询重写默认要求「语义等价」，聚合物化视图无法服务于明细查询。但如果你的场景本质是「查某分区内的原始记录」，又希望利用 MV 的分区结构加速定位，就得绕过重写机制，改用物化视图作为分区元数据跳板。
实操建议：
- 用物化视图的分区信息反推基表分区名：
SELECT PARTITION_NAME FROM USER_TAB_PARTITIONS WHERE TABLE_NAME = 'MV_SALES' AND TO_CHAR(HIGH_VALUE) LIKE '%2024-01%'（注意HIGH_VALUE是 LONG 类型，需 TO_CHAR 转换后模糊匹配） - 手动构造分区限定查询：
SELECT * FROM SALES PARTITION (SYS_P123) WHERE ...，避免全表扫描 - 此方式不依赖重写，但需定期同步 MV 分区与基表分区的映射关系（如通过
USER_OBJECTS.CREATED时间戳或自定义日志表）
刷新策略导致物化视图分区与基表不同步
快速刷新（FAST）只更新变更行，不会重建分区结构；若基表新增分区而 MV 未同步，查询跨新分区时必然回退到基表。更隐蔽的是，基表分区交换（EXCHANGE PARTITION）后，MV 若未刷新，其内部快照仍指向旧段。
实操建议：
- 对分区增删操作，强制触发
DBMS_MVIEW.REFRESH并指定METHOD => 'C'（COMPLETE），确保 MV 分区拓扑与基表一致 - 监控
USER_MVIEWS.REFRESH_MODE和REFRESH_METHOD，避免设成DEMAND+FAST的组合——它无法响应 DDL 级分区变更 - 在基表分区维护脚本中，追加调用
DBMS_MVIEW.REFRESH_DEPENDENT，参数OBJECT_LIST => ('SALES')，自动刷新所有依赖该表的 MV
分区裁剪和物化视图重写的交集区域非常脆弱，一个括号位置不对、一次忘记收集统计信息、一次分区交换后的遗漏刷新，都足以让查询彻底脱轨。盯住 HIGH_VALUE 的实际值、LAST_ANALYZED 的时间戳、REFRESH_MODE 的真实含义，比调优 SQL 本身更关键。
