物化视图本身不支持分区消除，只有其底层分区基表在查询重写生效且满足分区键谓词等条件下，执行计划才可能出现partition range iterator。
查执行计划里有没有PARTITION RANGE ITERATOR
物化视图本身不直接“支持分区消除”，能用上分区裁剪的是它底层的基表或物化视图所依赖的本地表。如果你建的物化视图基于一张已分区的本地表（比如sales_remote_copy按sale_date做了RANGE分区），且查询条件中包含分区键谓词（如WHERE sale_date >= DATE '2025-01-01'），那执行计划里才可能出现PARTITION RANGE ITERATOR或PARTITION RANGE SINGLE——这说明优化器成功跳过了无关分区。
关键点在于：物化视图定义语句里不能带@dblink，否则整个执行路径会退化为REMOTE操作，分区信息完全不可见。
- 必须用
EXPLAIN PLAN FOR查看真实计划，别信DBMS_MVIEW.EXPLAIN_REWRITE的返回结果——它只管重写是否发生，不管分区裁剪 - 如果物化视图是
ON DEMAND刷新，且基表分区策略和本地复制表不一致（比如远程表按月分区，本地表没分区或按年分），PARTITION RANGE节点根本不会出现 - 即使计划里有
PARTITION RANGE，也要核对OBJECT_NAME列是否指向你的物化视图名（如MV_SALES_LOCAL）；如果是基表名，说明查询没走MV重写，只是碰巧基表自己被裁剪了
确认物化视图是否启用QUERY REWRITE且SQL被真正重写
分区消除的前提是查询真正在用物化视图，而不是绕过去查基表。Oracle只有在启用查询重写、且SQL语义匹配时，才会把原查询映射到MV上——而MV若建在分区表上，才可能触发后续的分区裁剪。
检查步骤：
- 确认
QUERY_REWRITE_ENABLED = TRUE，且物化视图创建时加了ENABLE QUERY REWRITE - 执行
DBMS_MVIEW.EXPLAIN_REWRITE('SELECT * FROM sales@remote_db WHERE dt > ...', 'MV_SALES_LOCAL')，返回REWRITE_MECHANISM = 'TEXT_MATCH'才算重写生效 - 若返回
REWRITE_CANNOT_BE_USED，常见原因是SQL含@dblink、或MV定义里用了不支持重写的函数（如SYS_CONTEXT） - 重写成功后，再看执行计划里
OBJECT_NAME是否变成物化视图名，并叠加PARTITION RANGE操作
物化视图日志和FAST刷新对分区消除没影响，但会影响可用性
MATERIALIZED VIEW LOG的存在与否，不影响分区消除是否发生——它只决定能否做FAST REFRESH。但如果你依赖FAST REFRESH来维持物化视图数据新鲜度，而日志表没建在分区表上，或者没包含分区键列，就可能导致刷新失败，进而让物化视图状态变成STALENESS = 'STALE'或'UNUSABLE'，最终查询根本走不到它上面。
- 建日志时要显式包含分区键列：
CREATE MATERIALIZED VIEW LOG ON sales_remote_copy WITH ROWID, SEQUENCE (sale_date) INCLUDING NEW VALUES - 如果日志表本身没分区，大容量变更下
FAST REFRESH可能变慢，但不会阻止分区消除——前提是物化视图还处于FRESH状态 - 一旦
STALENESS != 'FRESH'，哪怕执行计划里显示走了MV，实际数据也可能陈旧或查询直接报错
金仓数据库（KingbaseES）中分区消除行为基本一致，但需注意ROWID兼容细节
金仓数据库在Oracle兼容模式下，对分区表+物化视图+查询重写的组合支持良好，执行计划中同样会出现PARTITION RANGE类节点。但它要求物化视图必须显式声明WITH ROWID，否则FAST REFRESH无法准确定位变更行，容易导致刷新中断或数据不一致——这种中断会让物化视图进入UNUSABLE状态，间接破坏分区消除的前提。
- 建物化视图时务必加上
WITH ROWID选项：CREATE MATERIALIZED VIEW mv_sales LOCAL ... AS SELECT ... FROM sales_remote_copy - 金仓的
ROWID虽语义对齐Oracle，但内部结构不同；若从Oracle导出DDL未适配，直接执行可能报错或刷新异常 - 迁移过程中最容易忽略的是：物化视图日志表是否也同步做了分区？金仓要求日志表分区策略与基表严格一致，否则
FAST REFRESH会拒绝执行
分区消除不是开关式功能，它依赖基表分区、物化视图可用性、查询重写生效、执行计划落地四个环节全部到位。任何一个环节断开，你看到的都只是“看起来像分区裁剪”的假象。
