根本原因是oracle默认查询重写仅支持完全匹配，对分区键谓词偏移或函数包装（如trunc(dt)）不识别；需确保查询列名与mv分区键严格一致、禁用函数包裹，并检查explain_rewrite中rewrite_mechanism及message提示。
物化视图查询重写未触发，dbms_mview.explain_rewrite 显示 qsm-01150: no suitable materialized view found
根本原因不是分区没建好，而是 oracle 默认的查询重写策略（query_rewrite_enabled=true）只启用“完全匹配式重写”，对含分区键过滤但谓词位置偏移、或存在函数包装的查询直接放弃。比如源表用 dt >= date '2024-01-01'，而物化视图按 trunc(dt) 分区，oracle 就不认为能剪枝。
实操建议：
- 先运行
DBMS_MVIEW.EXPLAIN_REWRITE，确认返回的具体失败原因行——重点看REWRITE_MECHANISM字段是否为NO_REWRITE，以及MESSAGE中是否出现partition key not used或expression not supported - 检查物化视图定义中是否显式写了
PARTITION BY RANGE且分区键与基表列完全一致（不能是表达式列）；若用了虚拟列或函数索引，重写引擎通常忽略分区信息 - 临时将参数调为
QUERY_REWRITE_INTEGRITY=STALE_TOLERATED，排除因物化视图状态为STALE导致的静默跳过
物化视图已按日期分区，但 SELECT * FROM mv WHERE dt BETWEEN ... 仍全表扫描
Oracle 的分区剪枝发生在物化视图本身被访问时，而非基表。如果查询重写没发生，优化器压根不会碰物化视图，自然谈不上剪枝。常见陷阱是：谓词列名和分区键名不一致（如基表用 event_time，MV 用 log_date），或查询中用了 NVL(dt, sysdate) 这类非确定性函数包裹。
实操建议：
- 确保查询中过滤的列名与物化视图 DDL 中的分区键列名**一字不差**，包括大小写（若用双引号定义）
- 避免在 WHERE 子句中对分区键列使用任何函数、类型转换或空值处理逻辑；宁可改写为
dt >= ... AND dt ，也不要写 <code>TRUNC(dt) = DATE '2024-01-01' - 用
EXPLAIN PLAN FOR查看执行计划，确认OBJECT_NAME是否为物化视图名，并观察PARTITION_START/PARTITION_STOP是否显示具体分区号（如KEY表示未剪枝，3和5表示实际访问了分区 3–5）
启用 QUERY_REWRITE_INTEGRITY=TRUSTED 后重写生效，但数据一致性风险怎么控？
TRUSTED 模式允许 Oracle 在物化视图状态为 STALE 时也强制重写，前提是 DBA 手动保证刷新及时性。它不校验 MV 内容是否真实反映基表，所以一旦刷新延迟或失败，查询结果就错。
实操建议：
- 仅对变更频率低、且有强刷新 SLA 的场景用
TRUSTED；高并发交易类系统禁用 - 配合
ON COMMIT刷新 +FAST刷新日志，比ON DEMAND更可控；但注意ON COMMIT会延长事务提交时间 - 必须建立监控：查
USER_MVIEWS.REFRESH_MODE和LAST_REFRESH_DATE，并用DBMS_MVIEW.REFRESH_DEPENDENT定期验证依赖链是否断裂
分区键是组合字段，比如 (region, dt)，但查询只过滤 dt，剪枝失效
Oracle 要求组合分区键的**前导列必须参与过滤**才能剪枝。只写 WHERE dt = ... 不触发剪枝，哪怕 dt 是第二列；必须加上 region = 'CN' 或 region IN ('CN','US') 才行。
实操建议：
- 若业务无法提供
region值，考虑重构分区策略：改用单列dt分区，或用RANGE-LIST复合分区，把region作为子分区键（此时主分区剪枝仍可基于dt） - 不要依赖
DBMS_MVIEW.REFRESH_ALL_MVIEWS自动推导；手动指定刷新范围时，必须传入完整分区键值列表，否则可能漏刷 - 测试阶段用
ALTER SESSION SET "_query_rewrite_driven"=FALSE临时禁用重写，对比原始查询与 MV 查询结果是否一致，再放开
分区剪枝能否生效，最终取决于查询重写是否真正落地——而重写是否落地，又卡在谓词形式、分区键对齐、刷新状态、完整性模式这四个硬约束上。少一个条件，优化器就退回原表扫描，连物化视图的边都不会碰。
