COMPRESS FOR OLTP仅在批量插入后长期只读或更新集中于少数列且不触发行迁移时有效；对频繁更新的短生命周期行无效，甚至增大楼体积。
OLTP压缩在什么场景下真能减小段体积？
直接说结论：compress for oltp 对「频繁更新的短生命周期行」基本无效，甚至可能让段更大；它只在满足特定访问模式时才压缩生效——即：批量插入后长期只读、或更新集中在少数列且不触发行迁移。
Oracle 的 OLTP 压缩本质是字典压缩 + 行内重复值消除，但所有压缩操作都依赖 ASSM 段管理下的块级重组。如果表持续高并发 DML，块频繁分裂、行迁移、ITL 争用，压缩字典根本来不及建立或立即失效。
- 适合场景：
INSERT /*+ APPEND */批量加载后转为只读/低频更新的历史分区表 - 不适合场景：带主键自增
ID、时间戳CREATED_AT、频繁UPDATE ... SET STATUS = 'PROCESSED'的事务表 - 验证方法：对比
SELECT SEGMENT_NAME, BYTES FROM USER_SEGMENTS和SELECT TABLE_NAME, COMPRESSION, COMPRESS_FOR FROM USER_TABLES，再查V$TABLESPACE中对应SEGMENT_SPACE_MANAGEMENT必须是AUTO
为什么加了 COMPRESS FOR OLTP 段体积反而变大？
常见错误是建表时加了 COMPRESS FOR OLTP，但没关 LOGGING 或没调 PCTFREE，导致每个数据块预留空间失控。
OLTP 压缩需要额外空间存字典头和符号映射表，Oracle 默认按 PCTFREE 10 预留空闲空间——而压缩块对空闲空间更敏感，稍一不足就拒绝压缩，退化成普通块，还多占了字典元数据。
- 必须显式设
PCTFREE 0或1（仅适用于加载后不再更新的场景） - 建表时务必加
NOLOGGING，否则重做日志会记录未压缩前的原始块格式，间接拖慢压缩生效速度 - 已存在数据的表不能靠
ALTER TABLE ... COMPRESS FOR OLTP立即生效，必须ALTER TABLE ... MOVE或在线重定义，否则老块永远不压缩
MOVE 时怎么避免锁表太久又保证压缩生效？
ALTER TABLE t MOVE COMPRESS FOR OLTP 是最常用手段，但它会锁全表、阻塞 DML，且默认使用 LOGGING，重做量巨大。
关键不是“能不能”，而是“怎么切得干净”：压缩只作用于新分配的数据块，MOVE 过程中 Oracle 会把原块数据解压→重排→按新规则压缩写入，所以必须确保 MOVE 后立刻禁用旧路径访问，并清理物化视图日志、索引等残留引用。
- 优先用
DBMS_REDEFINITION在线重定义，尤其当表有外键、物化视图日志或正在被复制时 - 若必须
MOVE，加上NOCOMPRESS参数先取消旧压缩（如有），再加COMPRESS FOR OLTP PCTFREE 1显式指定 - MOVE 后立刻执行
ALTER INDEX ... REBUILD ONLINE，否则索引仍指向旧块地址，查询可能报ORA-08102（索引键不存在） - 别忘了
ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE校验压缩后结构一致性
压缩后查询变慢？检查这三个地方
压缩不是免费午餐。CPU 解压开销、缓存效率下降、执行计划失真，都会让原本快的查询突然卡住。
最常被忽略的是统计信息陈旧：DBMS_STATS.GATHER_TABLE_STATS 在压缩后必须重跑，否则优化器仍按未压缩估算块数和 I/O 成本，可能选错索引或走全表扫描。
- 确认
USER_TAB_STATISTICS中COMPRESSION列是ENABLED，且LAST_ANALYZED是 MOVE 之后的时间 - 查
V$SQL中相关 SQL 的CPU_TIME和ELAPSED_TIME是否明显升高，配合DBMS_XPLAN.DISPLAY_CURSOR看是否出现TABLE ACCESS STORAGE FULL（说明走了压缩块全扫） - 如果用了函数索引或虚拟列，确保它们定义中没隐式转换（如
TO_CHAR(CREATED_AT)），否则无法利用压缩块中的原始存储格式
压缩真正起效的边界很窄：数据重复率高、更新稀疏、统计信息准、索引设计匹配。漏掉其中任一环，结果就是空间没省多少，性能先掉下去了。
