必须先确认advanced compression许可已启用，否则hcc无效；执行select value from v$option where parameter = 'advanced compression'返回true才生效；compress for query low等语法仅在直接路径操作时触发物理压缩；验证需看dba_segments.bytes下降、physical_reads_direct升高及compress_for明确值。
必须先确认 Advanced Compression 许可已启用，否则所有 HCC 语法都只是摆设。
查 V$OPTION 确认 Advanced Compression 是否真正开启
执行 SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Advanced Compression';，返回值必须是 TRUE。若为 FALSE，哪怕后续执行 COMPRESS FOR QUERY LOW 成功，Oracle 也只会按 BASIC 压缩处理——不走列级字典、不编码、块大小不变、查询性能无改善。
常见误操作：看到 ALTER TABLE ... COMPRESS FOR QUERY LOW 没报错，就以为 HCC 生效了。其实它连元数据都没改对，USER_TABLES.COMPRESS_FOR 可能仍是空或 ENABLED，而非具体级别。
创建或迁移表时指定 HCC 压缩级别
HCC（Hybrid Columnar Compression）只在直接路径插入（如 INSERT /*+ APPEND */）、CREATE TABLE AS SELECT 或 ALTER TABLE ... MOVE 时触发物理压缩。普通 DML 不压缩已有数据。
-
COMPRESS FOR QUERY LOW：用 LZO，压缩比约 89%，适合频繁扫描但更新少的报表表 -
COMPRESS FOR ARCHIVE HIGH：用 bzip2，压缩比可达 97.5%，适合冷数据归档，CPU 开销最高 - 分区表可混合使用：
PARTITION p1 COMPRESS FOR QUERY LOW+PARTITION p2 COMPRESS FOR ARCHIVE HIGH
注意：COMPRESS FOR OLTP 和 ROW STORE COMPRESS ADVANCED 属于行压缩，不是 HCC；它们不改变存储格式，也不具备列式特性。
验证 HCC 是否真实生效的三个硬指标
别只看 DBA_TAB_PARTITIONS.COMPRESS_FOR 字段，盯住这三个值才说明压缩落地了：
-
DBA_SEGMENTS.BYTES：同一段移动前后对比，MB 级下降才算数（例如从 104 MB → 68 MB） -
V$SEGMENT_STATISTICS.PHYSICAL_READS_DIRECT：显著偏高，说明 Oracle 正在读取压缩块（HCC 块需 direct path 读） -
DBA_TABLES.COMPRESSION必须为ENABLED，且COMPRESS_FOR明确显示QUERY LOW、ARCHIVE HIGH等具体值，不能是BASIC或空
HCC 的压缩效果高度依赖数据重复度和列分布。如果某列全是唯一值（如主键），该列几乎不压缩；而时间戳+状态码+枚举字段组合，往往能压出 15:1 以上的实际节省比。
MOVE 表或分区启用 HCC 的实操要点
对现有表启用 HCC，最常用的是 ALTER TABLE ... MOVE COMPRESS FOR QUERY LOW，但极易踩坑：
- 必须带
NOLOGGING（除非你明确要归档日志）——否则 redo 膨胀抵消空间收益 - MOVE 会重建整个段，期间锁表（非 ONLINE），业务写入会阻塞；如需在线，得用
ALTER TABLE ... MOVE PARTITION ... ONLINE（仅限 12c 及以上） - MOVE 后局部索引失效，必须显式重建：
ALTER INDEX idx_name REBUILD PARTITION p1; - 全局索引可能变为
UNUSABLE，务必查DBA_INDEXES.STATUS，漏掉这步会导致后续查询报ORA-01502
HCC 不是“设个参数就完事”的功能。它本质是一次物理重组织，需要预留足够临时表空间、评估 CPU 和 I/O 峰值、并避开业务高峰。压缩前后的空间差，才是唯一可信的验收标准。
