物化视图压缩属性必须建表时指定，alter不生效；仅能通过drop/create重建或alter table修改底层表；需按场景选compress basic或for oltp，并对分区逐个压缩。
物化视图必须 CREATE 时加 COMPRESS，ALTER 不生效
物化视图的压缩属性无法事后修改。执行 ALTER MATERIALIZED VIEW mv_name COMPRESS 会直接报错 ORA-00922: missing or invalid option。这是 Oracle 的硬限制——底层表虽可压缩，但 DDL 层不开放切换接口。
真正可行的路径只有两条：
- 先
DROP MATERIALIZED VIEW mv_name，再用CREATE MATERIALIZED VIEW ... COMPRESS FOR OLTP（或COMPRESS BASIC）重建 - 跳过 MV DDL，直接对底层存储表操作：
ALTER TABLE mv_name COMPRESS FOR OLTP（需 DBA 权限，且刷新期间可能锁表）
注意：即使物化视图建在已启用压缩的表空间里，若建 MV 时没写 COMPRESS，数据块仍是未压缩的——这是最常被忽略的前提。
COMPRESS FOR OLTP 和 COMPRESS BASIC 怎么选
选错类型会导致空间不降反升，或刷新性能暴跌。
COMPRESS BASIC 只对直接路径插入（如 INSERT /*+ APPEND */）生效；普通 INSERT/UPDATE 会解压整块，FAST 刷新时反复膨胀，适合只做一次性加载、极少更新的场景。
COMPRESS FOR OLTP 支持常规 DML 压缩，适合频繁刷新的 MV；但它要求企业版 + Advanced Compression 选件，否则建表时报 ORA-64307。
验证当前状态用：SELECT table_name, compression, compress_for FROM user_tables WHERE table_name = 'MV_NAME'，重点看 compress_for 字段值是否符合预期。
分区物化视图要逐分区压缩才真正省空间
给整个 MV 加 COMPRESS 效果有限；冷数据长期滞留却无法释放，关键得靠分区级压缩。
前提：分区键必须与基表对齐（aligned），否则 FAST 刷新会失效。例如基表按 sale_date 范围分区，MV 也得用 TRUNC(sale_date, 'MM') 分区。
建 MV 时每个分区单独声明压缩：PARTITION p_202501 COMPRESS FOR OLTP；已有分区可用：ALTER MATERIALIZED VIEW mv_name MODIFY PARTITION p_202501 COMPRESS FOR OLTP。
老分区不用 DELETE 或 TRUNCATE，直接 DROP PARTITION 更快，且几乎不产生 undo/redo。
空间没降下来？先查基表和日志
加了 COMPRESS 还占满空间，大概率不是压缩没生效，而是其他环节在“偷偷吃空间”。
- 基表本身未压缩：
MV只压缩自己，不压缩源表；如果基表数据冗余严重，MV 刷新时会把膨胀数据原样复制过来 - 物化视图日志（
MATERIALIZED VIEW LOG）没清理：日志表持续增长，尤其在低带宽或频繁刷新场景下，可能比 MV 本体还大 -
IDL_UB1$表爆涨：批量刷新触发 PL/SQL 重编译，该系统表会在SYSTEM表空间中无节制膨胀，需定期清理
压缩只是手段，不是万能解药；真正省空间得从基表、日志、分区、系统表四头并进，缺一不可。
