物化视图支持compress，但必须在create时显式声明，不继承表空间默认压缩设置，且无法通过alter修改，只能重建；常见空间仍大的原因包括基表未压缩、mlog$日志未清理、使用complete刷新及未启用段级压缩。
物化视图空间爆满，不是立刻建新表空间或盲目扩容，而是先看它能不能“瘦身”——分区 + 压缩是生产环境最可控、副作用最小的释放路径。
物化视图本身支持 COMPRESS 吗？
支持，但必须显式声明。Oracle 不会继承表空间的 default compress 设置，也不会自动对物化视图启用压缩。
-
CREATE MATERIALIZED VIEW语句中必须带上COMPRESS关键字，否则即使建在压缩表空间里，数据块仍是未压缩存储 - 不支持
ALTER MATERIALIZED VIEW ... COMPRESS—— 修改压缩属性只能重建，不能原地切换 - 压缩方式影响行为：
COMPRESS FOR OLTP对常规 DML 更友好；COMPRESS BASIC仅对直接路径加载（如INSERT /*+ APPEND */）生效，普通 insert/update 会解压
示例：
CREATE MATERIALIZED VIEW mv_sales_summary COMPRESS FOR OLTP BUILD IMMEDIATE REFRESH FAST ON COMMIT AS SELECT region, SUM(amount) total_amt FROM sales GROUP BY region;
为什么物化视图加了 COMPRESS 还占很多空间？
常见原因不是压缩没起作用，而是物化视图底层用了非压缩基表、或刷新机制导致重复膨胀。
- 基表未压缩：物化视图只压缩自身存储，不压缩源表。如果基表本身冗余高、无压缩，MV 刷新时仍要读大量原始块，且压缩率受限于数据分布
- 快速刷新日志（MLOG$）未清理：每次
FAST刷新都依赖物化视图日志，这些日志表若长期不 purge，会持续占用空间，且不参与 MV 的COMPRESS - 刷新方式为 COMPLETE：全量重建时，旧 MV 段不会立即释放，而是在事务提交后才 drop，期间存在双份数据
- 未启用段压缩（Segment-level compression）：仅靠
COMPRESS是行压缩，若数据块内重复值少，效果有限；可配合ALTER TABLE ... MOVE COMPRESS FOR OLTP强制重组织段
分区物化视图怎么设才能兼顾空间和刷新效率？
分区不是为了“看起来整齐”，而是让空间释放和刷新变成可切片操作。关键在分区键选择和刷新策略协同。
- 按时间列分区（如
TRUNC(refresh_time, 'MM')）最常用，便于滚动窗口清理：只需DROP PARTITION老分区，不锁全表，也不触发大范围重写 - 分区 MV 必须基于已分区的基表，且分区键需与基表对齐（aligned），否则无法使用
FAST刷新 - 每个分区可独立压缩：
ALTER MATERIALIZED VIEW mv_name MODIFY PARTITION p_202501 COMPRESS FOR OLTP，避免全量重建 - 禁止跨分区刷新：如果业务允许延迟，用
ON DEMAND+DBMS_MVIEW.REFRESH指定单个分区，比全量COMPLETE节省 70%+ I/O 和临时段空间
空间告警后，最快见效的三步操作
别急着联系 DBA 扩容，先执行这三项低风险动作：
- 查当前 MV 占用：
SELECT segment_name, bytes/1024/1024 MB FROM dba_segments WHERE segment_name = 'MV_NAME' AND owner = 'SCHEMA_NAME' - 删过期日志：
EXEC DBMS_MVIEW.PURGE_LOG('SCHEMA_NAME', 'MLOG$_BASE_TABLE')（注意：确保无其他 MV 依赖该日志） - 收缩并重压缩：先
ALTER MATERIALIZED VIEW mv_name NOLOGGING，再ALTER MATERIALIZED VIEW mv_name REBUILD COMPRESS FOR OLTP—— 这一步会重建段、丢弃空闲块、强制应用压缩
真正难的是判断“该不该分区”：如果物化视图每天增量稳定、历史数据只读、查询常带时间过滤，那分区 + 压缩就是必选项；如果查询总是跨全量时间范围、且更新频繁，强行分区反而增加维护成本和刷新延迟。
