DELETE仅标记行删除而不回收空间、不降低HWM，导致全表扫描仍遍历空块；TRUNCATE可重置HWM但不可回滚；SHRINK SPACE需启用行移动且要求LMT+AUTO管理；文件缩容须先收缩再RESIZE。
DELETE 为什么删了数据却占着空间不放
因为 delete 只是把行标记为“已删除”，并不回收数据块，更不会动高水位线（hwm）。hwm 就像水库的历史最高水位——水抽干了，水位碑还在原地。oracle 全表扫描时仍会一路扫到 hwm，哪怕中间全是空块。
-
DELETE是 DML 操作，受事务控制，可回滚；但回滚段清理滞后、未提交的事务都会让空间长期“挂着” - HWM 不会自动下降，哪怕你删光整张表，
BLOCKS字段在USER_TABLES里依然显示旧值 - 频繁增删后，HWM 下方堆积大量碎片块，
INSERT /*+ APPEND */还可能直接往 HWM 上方追加，进一步推高水位
怎么查当前表的 HWM 和真实占用
不能只看 USER_SEGMENTS.BYTES，那只是段分配总量；得结合块级统计才能判断“有多少是真用的、多少是空着但被 HWM 锁住的”。
- 先做分析：执行
ANALYZE TABLE your_table_name ESTIMATE STATISTICS（或用DBMS_STATS.GATHER_TABLE_STATS更推荐） - 查关键指标：
SELECT blocks, empty_blocks, avg_space, chain_cnt FROM user_tables WHERE table_name = 'YOUR_TABLE_NAME'——blocks就是当前 HWM 对应的数据块总数 - 算真实使用率：可用
(blocks - empty_blocks) * 8192估算实际有数据的字节数（单位字节），和BYTES对比，差值就是 HWM 下的“幽灵空间”
释放空间的三种实操路径及适用场景
没有银弹，选哪种取决于你是否能停业务、有没有外键、要不要保留表结构。
-
快速清空 + 重置 HWM：用
TRUNCATE TABLE your_table_name DROP STORAGE—— 立即释放全部空间、HWM 归零，但不可回滚，且不能有外键引用（否则报ORA-02266） -
在线收缩（需启用行移动）：顺序执行三步
ALTER TABLE your_table_name ENABLE ROW MOVEMENT→ALTER TABLE your_table_name SHRINK SPACE COMPACT→ALTER TABLE your_table_name DISABLE ROW MOVEMENT；适合不能停服的场景，但要求表没启用 Flashback Data Archive，且会短暂锁表 -
只释放 HWM 上方未用空间：用
ALTER TABLE your_table_name DEALLOCATE UNUSED KEEP 0—— 不动 HWM，只把分配了但完全没写过数据的块还给表空间；见效小，常作为收缩前的轻量清理
收缩完为什么磁盘文件还是那么大
HWM 降了，不代表数据文件（datafile）自动缩小。Oracle 不会主动把文件“切掉一截”，必须手动 RESIZE，而且有严格前提。
- 先确认能缩多少：查
dba_data_files和dba_extents，算出该文件最后一个已用块的位置，再换算成字节数（比如MAX(block_id + blocks) * 8192） - 执行
ALTER DATABASE DATAFILE '/path/to/file.dbf' RESIZE <new_size>时，如果报ORA-03297，说明你要砍掉的区域里还有 Extent 分配着——不是没数据，是 Oracle 认为它“可能还要用” - 真正安全缩容前，往往得先
SHRINK SPACE表，再COALESCE表空间（对字典管理表空间无效），最后才RESIZE；跳过前面两步，RESIZE基本都会失败
最常被忽略的一点：SHRINK SPACE 要求表所在表空间是本地管理（LMT）且段空间管理方式为 AUTO（不是 MANUAL）。用 DBA_TABLESPACES 查 SEGMENT_SPACE_MANAGEMENT 字段，是 MANUAL 的话，SHRINK 直接报错，连试都不让试。
