根本原因是oracle查询重写对分区键匹配要求字面一致且约束必须validated；需确保查询谓词与mv分区列名及表达式完全相同、基表主键为enabled validated，并用dbms_mview.explain_rewrite验证qsmqt_unrewrite等提示。
QUERY_REWRITE_ENABLED 开了、物化视图也建了、分区结构看着也对，但查询就是不走 MV —— 根本原因不是“无法启用”，而是重写引擎在分区场景下默认拒绝语义模糊的匹配。Oracle 不会为含函数包装、列名错位或约束缺失的查询冒险重写，哪怕物理结构完全一致。
物化视图分区键与查询谓词必须字面一致
Oracle 查询重写对分区键的匹配是字面级（literal）的，不推导、不归一化、不兼容隐式转换。
- 物化视图按
TRUNC(sale_date)分区 → 查询中写sale_date >= DATE '2024-01-01'，重写失败 - 物化视图分区列为
log_dt（小写），而查询写WHERE LOG_DT >= ...（大写且未加双引号），若数据库区分大小写则不匹配 - 查询中用了
NVL(sale_date, SYSDATE)或TO_CHAR(sale_date, 'YYYY-MM')→ 重写直接跳过，因为优化器无法证明等价性 - 正确做法：查询必须直接作用于物化视图 DDL 中声明的**物理分区列名**，且表达式完全相同，例如
WHERE TRUNC(sale_date) = DATE '2024-01-01'
QUERY_REWRITE_INTEGRITY=ENFORCED 时基表约束必须 VALIDATED
默认 ENFORCED 模式下，Oracle 要靠约束验证结果来确认分区键值的唯一性和完整性。如果基表主键是 NOVALIDATE，即使物化视图日志存在、刷新正常，重写也会静默失效。
- 查约束状态：
SELECT CONSTRAINT_NAME, STATUS, VALIDATED FROM USER_CONSTRAINTS WHERE TABLE_NAME = 'SALES' AND CONSTRAINT_TYPE = 'P'，必须是ENABLED VALIDATED - 修复命令：
ALTER TABLE sales MODIFY CONSTRAINT pk_sales ENABLE VALIDATE（注意：全量校验可能锁表、耗时） - 若不能校验，可临时设会话级
ALTER SESSION SET query_rewrite_integrity = TRUSTED，但需配合RELY约束，例如ALTER TABLE sales MODIFY CONSTRAINT pk_sales RELY ENABLE NOVALIDATE
DBMS_MVIEW.EXPLAIN_REWRITE 显示 QSMQT_UNREWRITE 就是分区断层信号
这个返回码比执行计划更早暴露问题——它说明重写逻辑在语义校验阶段就失败了，还没走到成本估算。
- 运行：
EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT * FROM sales WHERE sale_date >= DATE ''2024-01-01''', 'MV_SALES') - 查
REWRITE_MECHANISM字段：若为NO_REWRITE，再看MESSAGE是否含partition key not used或expression not supported - 若提示
QSM-01150: rewrite not possible due to missing or invalid constraints，说明约束或日志不满足ENFORCED要求，不是分区本身的问题 - 不要只看
EXPLAIN PLAN；它可能显示走基表，但掩盖了重写被提前否决的事实
物化视图未分析或统计信息陈旧会导致分区裁剪失效
即使重写成功触发，访问的是物化视图，但如果它的分区统计信息缺失，CBO 仍会误判为全分区扫描。
- 检查：
SELECT PARTITION_NAME, NUM_ROWS, LAST_ANALYZED FROM USER_TAB_PARTITIONS WHERE TABLE_NAME = 'MV_SALES'，若NUM_ROWS全为NULL或LAST_ANALYZED过期，裁剪大概率失效 - 强制收集：
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => USER, tabname => 'MV_SALES', granularity => 'ALL', cascade => TRUE) - 对比基表与 MV 的
LAST_ANALYZED时间戳，两者偏差超过 1 天就建议同步更新 - 测试 hint：
SELECT /*+ REWRITE(MV_SALES) */ * FROM sales WHERE sale_date >= DATE '2024-01-01'，若执行计划立刻出现具体分区号（如PARTITION_START=3），说明纯属统计问题
真正卡住重写的，往往不是分区语法本身，而是你没意识到 Oracle 对“字面一致”和“约束可信”的执念有多强。一个空格、一个函数、一行没收集的统计，都足以让整个重写链路静默中断。
