物化视图未走分区裁剪主因是未显式声明PARTITION BY且与基表分区键不一致：必须严格匹配列名、数据类型及边界值，禁用别名、表达式或函数包装，并确认基表已启用ROW MOVEMENT。
查物化视图是否声明了PARTITION BY且与基表分区键一致
物化视图没走分区裁剪，八成是因为它根本没分区——哪怕基表按 sale_date 范围分区，MV 默认仍是单段。必须显式写 PARTITION BY RANGE(sale_date)，且列名、数据类型、边界值要和基表 USER_TAB_PARTITIONS 里的一致。大小写敏感（如果用双引号建的），别名、表达式列（如 TRUNC(sale_date)）全都不行。
实操建议：
- 运行
SELECT view_name, text FROM user_views WHERE view_name = 'YOUR_MV_NAME'确认定义中是否有PARTITION BY子句 - 对比基表分区键：
SELECT column_name FROM user_part_key_columns WHERE name = 'SALES' AND object_type = 'TABLE' - 检查 MV DDL 中的分区键是否为同一列、非计算列、未被函数包裹
验证查询重写是否真命中物化视图
即使 MV 分区了，查询也可能压根没走它。Oracle 查询重写默认只做“完全匹配”，WHERE dt >= DATE '2024-01-01' 能剪枝，但 WHERE TRUNC(dt) = DATE '2024-01-01' 就直接跳过。不查执行计划，你永远不知道优化器在用谁。
实操建议：
- 用
EXPLAIN PLAN FOR SELECT ...后查PLAN_TABLE，确认OBJECT_NAME是 MV 名，不是基表名 - 看
PARTITION_START和PARTITION_STOP：若显示KEY或范围远超预期（如 1–128），说明没剪枝 - 运行
DBMS_MVIEW.EXPLAIN_REWRITE，重点盯REWRITE_MECHANISM是否为TEXT_MATCH，MESSAGE里有没有partition key not used
扫描所有物化视图并标记未启用PCT或分区不匹配的
手动一个个查太慢。真正能批量识别“未对齐”的，是结合 USER_MVIEWS、USER_MVIEW_LOGS 和 USER_PART_KEY_COLUMNS 做关联判断。核心逻辑就两条：MV 定义里没写 PARTITION BY，或者写了但分区键不在基表分区键列表中。
实操建议：
- 跑这个语句快速筛出可疑 MV：
SELECT m.mview_name, m.build_mode, m.refresh_method, m.last_refresh_date FROM user_mviews m WHERE m.mview_name NOT IN ( SELECT DISTINCT mview_name FROM user_mview_logs l, user_part_key_columns p WHERE l.master = p.name AND l.log_table LIKE 'MLOG%' AND EXISTS ( SELECT 1 FROM user_mview_analysis a WHERE a.mview_name = m.mview_name AND a.capability_name = 'REFRESH_FAST_PCT' AND a.possible = 'Y' ) ); - 结果里
refresh_method是FAST但不在子查询中的，基本就是 PCT 没生效或日志缺失关键列 - 再补查
SELECT * FROM user_mview_capabilities WHERE mview_name = 'xxx'，确认REFRESH_FAST_PCT的possible是N还是报错信息含partition change tracking not supported
为什么ROW MOVEMENT漏配会导致“对齐假象”
很多 DBA 看到 MV 分区定义和基表一样，就以为万事大吉。但 PCT 生效有个隐藏前提：基表必须启用 ROW MOVEMENT。否则后续做 EXCHANGE PARTITION 或在线移动时，分区操作会失败，而错误提示里根本不会提 MV —— 它只报 ORA-14006，让人一头雾水。
实操建议：
- 查基表是否开
ROW MOVEMENT：SELECT table_name, row_movement FROM user_tables WHERE table_name = 'SALES' - 没开就立刻补：
ALTER TABLE SALES ENABLE ROW MOVEMENT - 这个动作不影响现有数据，但它是 PCT 能持续工作的底层保障，不是“可选项”
真正容易被忽略的是：分区对齐不是建一次就一劳永逸的事。基表加新分区、改高值、换分区键类型，都会让已有的 MV 分区定义瞬间失效；而 Oracle 不报错，只静默降级为全量刷新或拒绝重写。得把上面几个检查点做成定期巡检脚本，而不是等慢了才想起查。
