oracle 19c索引段不支持shrink space，仅能通过rebuild或coalescecleanup整理碎片；执行shrink会报ora-01735错误，因该命令仅适用于堆表段，索引空间优化必须依赖重建操作。
oracle 19c 的索引段本身不支持 shrink space，不是“无法在线收缩”，而是根本不能 shrink —— 这是设计限制，不是权限、锁或参数问题。
SHRINK SPACE 对索引段完全无效
Oracle 的 SHRINK SPACE 命令只适用于堆表（TABLE）段，且要求启用行移动（ENABLE ROW MOVEMENT）。索引段（INDEX）无论是否带 ONLINE，都不在 SHRINK 支持范围内。执行 ALTER INDEX idx_name SHRINK SPACE 会直接报错 ORA-01735: invalid ALTER INDEX option。
- 官方文档明确将
SHRINK归类为“仅适用于堆组织表”的操作 - 索引结构（B-tree）的碎片整理逻辑与堆表不同，靠的是重建（
REBUILD），不是空间压缩 - 即使索引所在表空间启用了自动段空间管理（ASSM），也不改变这一限制
为什么有人误以为“能 shrink 索引”？
常见混淆来源是把“收缩索引所在的表空间”当成“收缩索引本身”。比如：
- 对索引所在表空间执行
ALTER TABLESPACE ... SHRINK SPACE—— 这个命令只影响永久表空间中的段（如表、物化视图），但不会触碰索引段；它实际收缩的是该表空间中可移动的堆表段释放出的空间 - 误读
DBA_SEGMENTS.bytes：看到索引段大小没变，就以为 shrink 失败；其实它压根没被 shrink 过 - 用
ALTER INDEX ... REBUILD ONLINE后发现空间变小了，误归因为 “shrink”，其实是 rebuild 清理了 B-tree 分支和叶节点空隙
真正能减小索引段体积的操作只有 REBUILD
想降低索引物理大小，必须重建。但要注意行为差异：
-
ALTER INDEX idx REBUILD：独占 DML 锁（TMmode=6），业务写入阻塞 -
ALTER INDEX idx REBUILD ONLINE：DML 不阻塞，但需额外空间（约 1.5× 原索引大小），且不支持函数索引、位图索引 - 重建后若未显式设
NOPARALLEL，索引DEGREE会保留并行度，后续查询可能意外触发并行，增加资源争用 - 重建不等于自动清理历史碎片：如果原索引长期高频率 DML，建议先
COALESCECLEANUP（如ALTER INDEX idx COALESCECLEANUP PARALLEL 4），再 rebuild
容易忽略的关键点
索引段没有“高水位线（HWM）”概念，它的空间使用由 B-tree 结构动态管理。所谓“收缩”，本质是重构树形路径、合并稀疏叶子块、释放未用分支节点。这个过程只能通过 REBUILD 或 COALESCECLEANUP 完成，且必须考虑事务一致性、空间预留和后台残留状态 —— 尤其是 ONLINE 中断后留下的 SYS_JOURNAL_* 段，不清理会导致后续所有索引操作失败。
