delete后空间不释放是oracle正常设计，仅标记数据块为可重用但hwm不降；需主动执行shrink space、truncate或重建表，并配合resize数据文件才能真正释放磁盘空间。
直接结论：DELETE 后空间不释放是正常行为，Oracle 只标记块为“可重用”，不会下调高水位线（HWM）或返还空间给操作系统。必须主动执行收缩、截断或重建操作才能真正回收。
为什么 DELETE 后 df -h 看不到空间减少
DELETE 是 DML 操作，仅将数据行标记为已删除，对应的数据块仍被段（segment）占用，HWM 不动，全表扫描仍需遍历这些空块。dba_free_space 视图里可能显示有空闲空间，但那是“段内空闲”，不是“表空间级可分配空间”。真正释放到操作系统层面，必须让 Oracle 释放 HWM 上方的区（extent）。
-
DELETE不产生空间回收，只生成大量 undo 和 redo - HWM 不下降 →
dba_extents中该表占用的 extent 数不变 - 表空间总使用率（
(bytes - free_bytes)/bytes）几乎无变化 - 常见误判：看到
dba_free_space有记录，就以为空间已释放 —— 实际是段内碎片，不可被其他对象使用
ALTER TABLE ... SHRINK SPACE 是最常用在线方案
适用于本地管理（LMT）、自动段空间管理（ASSM）的表，能在线下调 HWM 并释放空间回表空间。但必须满足前置条件，否则报 ORA-10635 或锁表现象。
- 先执行
ALTER TABLE table_name ENABLE ROW MOVEMENT—— 否则报ORA-10636 - 推荐分两步：
ALTER TABLE table_name SHRINK SPACE COMPACT（只整理、不调 HWM，业务影响最小），再ALTER TABLE table_name SHRINK SPACE（下调 HWM，需短暂 X 锁） - 加
CASCADE可同时收缩依赖索引：SHRINK SPACE CASCADE，避免索引碎片残留 - 执行后务必检查索引状态：
SELECT index_name, status FROM dba_indexes WHERE table_name = 'YOUR_TABLE'，失效索引需重建
TRUNCATE 更快但需业务停写
当整张表数据都要清空时，TRUNCATE TABLE 比 DELETE + SHRINK 快一个数量级，且天然重置 HWM、释放全部 extent。但它不是 DML，不可回滚，且会隐式提交并使依赖对象（如视图、包）失效。
-
TRUNCATE TABLE table_name DROP STORAGE（默认行为）→ 立即释放所有空间 -
TRUNCATE TABLE table_name REUSE STORAGE→ 保留分配的空间，仅清空数据（极少用） - 注意：TRUNCATE 不触发 ON DELETE 触发器，也不受外键约束阻塞（除非有引用完整性限制）
- 执行前确认无活跃查询或 DML，否则报
ORA-00054: resource busy
大表清理慎用 DELETE，优先考虑重建路径
对千万级以上表执行 DELETE WHERE ...，极易引发长事务、undo 溢出、redo 压力、锁升级甚至 ORA-01555 快照过旧。更稳妥的做法是“导出保留数据 → 截断 → 导入”或“创建新表 → 交换”。
- 安全做法：
CREATE TABLE new_table AS SELECT * FROM old_table WHERE keep_condition，再RENAME交换 - 若需保留原表名和权限，用
DBMS_REDEFINITION在线重定义（支持主键、索引、约束自动迁移） - 绝对避免在生产高峰执行全表
DELETE，尤其没加COMMIT分批 —— undo 表空间撑爆风险极高 - 执行后记得收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS，否则执行计划可能劣化
真正容易被忽略的是：SHRINK 或 TRUNCATE 后，表空间文件（.dbf）本身大小并不会缩小。要缩文件得单独 ALTER DATABASE DATAFILE ... RESIZE；而删整个表空间时，DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 也不等于磁盘空间立刻释放 —— 得看 lsof | grep deleted 是否还有进程持句柄。
