物化视图必须在create时显式指定compress，alter materialized view不支持修改压缩属性，唯一方法是drop重建或对底层表执行alter table compress；压缩类型需按刷新频率和版本选compress for oltp（企业版）或compress basic，并配合分区级压缩、基表压缩及日志清理才能真正节省空间。
物化视图必须在 create 时显式加 compress，否则哪怕建在压缩表空间里，数据块仍是未压缩的——这是最常被忽略的前提。
为什么 ALTER MATERIALIZED VIEW 不能加 COMPRESS？
Oracle 不允许用 ALTER MATERIALIZED VIEW ... COMPRESS 修改压缩属性。物化视图底层是一张普通表，但 DDL 层不开放压缩切换。试图执行会报错：ORA-00922: missing or invalid option。
- 唯一可行路径是
DROP后重建，或退而求其次：对底层表执行ALTER TABLE mv_name COMPRESS FOR OLTP（需注意权限和锁） - 重建前务必确认刷新策略是否支持中断——
ON COMMIT类型的 MV 重建期间基表 DML 会阻塞 - 若 MV 名为
mv_sales_daily，其实际存储表名通常也是MV_SALES_DAILY（可通过SELECT mview_name, table_name FROM user_mviews验证）
COMPRESS FOR OLTP 和 COMPRESS BASIC 怎么选？
选错压缩类型会导致空间节省失效，甚至影响刷新性能。
-
COMPRESS BASIC：仅对直接路径操作（如INSERT /*+ APPEND */）生效；普通INSERT或UPDATE会解压整块，后续 FAST 刷新可能反复膨胀 -
COMPRESS FOR OLTP：支持常规 DML 压缩，适合频繁刷新的场景；但要求企业版 + Advanced Compression 选件，否则报ORA-64307 - 验证是否启用：
SELECT table_name, compression, compress_for FROM user_tables WHERE table_name = 'MV_SALES_DAILY'—— 注意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 - 老分区可直接
DROP PARTITION清理，比DELETE或TRUNCATE更快且不产生大量 undo/redo
空间没降下来？先查这三个地方
加了 COMPRESS 还占满空间，大概率不是压缩没生效，而是其他环节在“偷偷吃空间”。
- 基表本身未压缩：MV 只压缩自己，不压缩源表；如果基表数据冗余高，MV 刷新时读取的原始块多，压缩率天然受限
- 物化视图日志（
MLOG$）堆积：FAST 刷新依赖日志表，长期不DBMS_MVIEW.PURGE_LOG会导致日志膨胀，这部分不参与 MV 的COMPRESS - 刷新方式为
COMPLETE：全量重建期间旧段未释放，临时占用双倍空间；建议改用FAST或FORCE，并确保基表有日志
压缩不是一劳永逸的开关，它依赖基表结构、刷新机制、分区设计三者协同；单独改 MV 的 COMPRESS 参数，就像只换轮胎不调四轮定位——能跑，但跑不远。
