delete分区表后表空间不释放是因为oracle仅逻辑删除数据、hwm不动且空间留待复用；truncate partition可释放空间但受限于依赖关系；shrink或move需分别处理分区并注意lob与索引状态。
为什么DELETE分区表后表空间不释放
Oracle对分区表执行 DELETE 时，只是逻辑标记行已删除，高水位线（HWM）完全不动，dba_extents 中的 extent 记录一条不少。哪怕删掉 99% 的数据，dba_segments.bytes 和 dba_tab_statistics.num_rows 仍严重脱节——前者显示几 GB，后者显示几十行。这不是“没释放”，而是 Oracle 故意不还：它把空间留着，等下次 INSERT 直接复用，避免频繁分配块的开销。
TRUNCATE PARTITION 能不能直接释放空间
能，但有硬限制：
-
TRUNCATE TABLE t1 DROP PARTITIONS (p2025q1, p2025q2)语法不合法 —— Oracle 不支持带 WHERE 或分区列表的TRUNCATE - 只能用
TRUNCATE PARTITION p2025q1，且该分区不能被物化视图日志、外键引用或全局索引依赖，否则报ORA-02266或ORA-02449 - 执行后该分区 segment 立即从
dba_extents消失，但所在表空间的 datafile 物理大小不变；如果分区含 LOB 列，需额外加INCLUDING DATA，否则 LOB 段残留
SHRINK SPACE 对分区表的实际效果
分区表上 SHRINK SPACE 不能跨分区自动合并空闲区，必须明确指定作用对象：
- 整表收缩：
ALTER TABLE t1 SHRINK SPACE—— 要求所有分区都启用行移动，且无不可收缩索引（如函数索引、域索引） - 单分区收缩：
ALTER TABLE t1 SHRINK SPACE PARTITION p2025q1—— 更安全，只锁该分区，不影响其他分区 DML - 收缩前必须先运行
ALTER TABLE t1 ENABLE ROW MOVEMENT，否则报ORA-10636；启用后ROWID可能变化，依赖ROWID的应用（如某些旧版缓存层）要验证
比 SHRINK 更快的替代方案：MOVE PARTITION
当分区数据极少（比如只剩几百行），MOVE PARTITION 往往比 SHRINK 更干脆：
-
ALTER TABLE t1 MOVE PARTITION p2025q1 TABLESPACE users;—— 直接重建分区物理结构，HWM 彻底重置 - MOVE 后本地索引自动失效，必须立刻重建：
ALTER INDEX idx_t1_local REBUILD PARTITION p2025q1 - 若分区含 LOB 字段，必须显式指定 LOB 存储位置：
MOVE PARTITION p2025q1 LOB (lob_col) STORE AS (TABLESPACE users) - 注意：MOVE 期间该分区不可读写，建议在维护窗口执行；全局索引不受影响，无需重建
真正卡住释放速度的，往往不是命令本身，而是没意识到分区级操作必须逐个处理，以及忽略 LOB 段和索引状态这两个最常漏掉的环节。
