Hash分区表上可建物化视图日志但不推荐，因哈希不可逆导致无法定位变更所属分区，使快速刷新失效并退化为完全刷新；仅RANGE/LIST分区支持PCT机制。
物化视图日志在 Hash 分区表上能建，但不推荐
Oracle 允许在 Hash 分区表上创建物化视图日志（CREATE MATERIALIZED VIEW LOG ON table_name），语法能通过，但实际效果差：日志本身无法按分区粒度记录变更，导致后续快速刷新（REFRESH FAST）失效或退化为完全刷新。
根本原因是：Hash 分区的分区键值经哈希函数映射后不可逆，Oracle 无法从日志中识别某条变更属于哪个具体分区；而快速刷新依赖“变更定位到分区”来实现增量处理。一旦失去分区级变更追踪能力，优化器就放弃 PCT（Partition Change Tracking），转而扫描全量日志甚至全表。
- 即使基表是 Hash 分区，日志仍是单个段（
USER_MVIEW_LOGS中LOGGING为 YES，但无分区信息） -
DBA_MVIEW_LOGS的LOG_TABLE列指向的是一张普通堆表，不是分区表 - 执行
DBMS_MVIEW.REFRESH('mv_name', 'F')时，V$MVREFRESH显示刷新类型为COMPLETE而非FAST，说明已降级
为什么 RANGE 分区 + 物化视图日志才真正支持 PCT
PCT（Partition Change Tracking）机制要求变更能精确归属到某个分区，只有 RANGE、LIST 等可判定边界的分区类型才能满足。Hash 分区因散列不可逆，Oracle 在内部无法将 ROWID 或主键映射回原始分区号。
例如：基表按 ORDER_ID HASH 8 分区，插入一条 ORDER_ID = 12345 的记录，Oracle 知道它落在 P3；但日志里只存了该行的 ROWID 和变更时间，没有保存“此 ROWID 属于 P3”的元数据——下次刷新时无法跳过其他分区。
- RANGE 分区表的日志可配合
ALTER TABLE ... ENABLE ROW MOVEMENT和UPDATE INDEXES实现安全迁移，Hash 表不支持这类操作 - Oracle 10gR2 起支持“无日志的 PCT”，但仅限 RANGE/LIST 分区，且要求基表启用
ENABLE ROW MOVEMENT - 若强行在 Hash 表上建日志并设
REFRESH FAST，首次刷新可能成功，但第二次起大概率报错ORA-12004: REFRESH FAST cannot be used
替代方案：避开 Hash 分区建日志的现实路径
如果业务已用 Hash 分区且必须用快速刷新，唯一可行路径是重构分区策略，而非硬扛日志性能问题。
- 改用
RANGE或LIST分区（如按时间、区域、状态等业务可枚举/有序字段） - 若必须保留 Hash 语义（如负载均衡），可在应用层加虚拟列：
ALTER TABLE t ADD (part_key AS MOD(order_id, 8))，再按该列做 LIST 分区 - 放弃快速刷新，改用
REFRESH COMPLETE ON DEMAND+ 并行刷新（ATOMIC_REFRESH => FALSE）降低锁影响 - 用物化视图本身分区（
PARTITION BY RANGE (log_date)）替代基表分区，把分区裁剪压力转移到 MV 层
检查当前日志是否真起作用的三步验证法
别信 DDL 是否成功，要看运行时行为。以下命令组合能暴露真实状态：
第一步，确认日志存在且含必要字段：SELECT LOG_TABLE, ROWIDS, PRIMARY_KEY FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE' —— 若 ROWIDS 为 NO，REFRESH FAST 必失败。
第二步，查最近一次刷新是否走快速路径：SELECT * FROM DBA_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV' AND LAST_REFRESH_DATE > SYSDATE - 1，再比对 LAST_REFRESH_DATE 和 V$MVREFRESH.LAST_REFRESH 中的 REFRESH_TYPE 字段值是否为 F。
第三步，最直接：手动触发一次刷新，同时监控 V$SEGMENT_STATISTICS 中基表各分区的 logical reads —— 如果所有分区读数都显著上升，说明没走分区裁剪，日志形同虚设。
Hash 分区表上的物化视图日志，本质是“语法允许但语义残缺”的设计妥协。真正要靠快速刷新撑住 OLAP 查询压力，得从分区类型源头选对路。
