truncate能立即释放空间并重置高水位线（hwm），而delete只标记行删除、不释放空间、hwm保持原位；前者是ddl操作，直接丢弃数据段并重建空结构，后者是dml操作，仅打删除标记且需额外收缩才能回收空间。
truncate 能立即释放空间并重置高水位线（hwm），而 delete 只标记行删除、不释放空间、hwm 保持原位——这是空间管理效果差异的根本原因。
TRUNCATE 为什么能真正释放表空间
TRUNCATE 是 DDL 操作，本质是“丢弃数据段 + 重建空结构”。它直接修改数据字典和区（extent）位图，把原分配的 extents 标记为“未使用”，立刻归还给表空间。即使表原本占了 100 个 extent，TRUNCATE 后 SELECT COUNT(*) FROM DBA_EXTENTS WHERE SEGMENT_NAME = 'T' 可能只剩 1 个（取决于 MINEXTENTS 设置）。
- 不依赖
COMMIT：执行即生效，无需手动提交 - 不受
REUSE STORAGE影响：默认就释放空间；加该子句只是保留原 extent 分配不归还，但依然不写行级日志 - 释放后空间可被其他对象（如新表、索引）立即复用
DELETE 为什么“删了也白删”——空间不释放的典型表现
DELETE 是 DML，只在数据块里把行打上“已删除”标记（DML delete flag），块本身仍被计入高水位线以下范围，且所有 extents 继续归属该表。哪怕你 DELETE FROM t 再 COMMIT，DBA_SEGMENTS.BYTES 和 DBA_EXTENTS.COUNT 完全不变。
- 常见误判：
SELECT COUNT(*) FROM t返回 0，就以为空间空了——其实物理空间一毛没少 - 后续 INSERT 会优先填这些“空块”，但全表扫描（如
SELECT * FROM t）仍要读到原 HWM，I/O 毫无改善 - 想回收空间？必须额外执行
ALTER TABLE t SHRINK SPACE或MOVE，而这需要行移动启用、加锁、耗时长
高水位线（HWM）差异直接影响查询与插入行为
HWM 不是元数据字段，而是 Oracle 扫描时的物理边界指针。DELETE 不动它，TRUNCATE 重置它——这个差别肉眼可见：
- DELETE 后：HWM 仍在高位，
SELECT /*+ FULL(t) */ COUNT(*) FROM t仍要读成千上万个空块 - TRUNCATE 后：HWM 回到
INITIAL大小（比如 64KB），下次INSERT从第一个块开始填，物理读锐减 - 验证方式：
ANALYZE TABLE t ESTIMATE STATISTICS后查DBA_TABLES.BLOCKS，对比前后值
容易被忽略的权限与约束限制
不是所有场景都能无脑换用 TRUNCATE。几个硬性卡点常导致 ORA-01702: a view is not appropriate here 或 ORA-02266: unique/primary keys in table referenced by enabled foreign keys：
- 不能对有外键引用的表直接
TRUNCATE TABLE；必须先DISABLE外键，或改用DELETE - 不能对视图、同义词、物化视图日志表执行
TRUNCATE - PL/SQL 块中必须用
EXECUTE IMMEDIATE 'TRUNCATE TABLE t'，不能直写语句 - 权限要求更高：
TRUNCATE需DROP ANY TABLE或表属主身份；DELETE只需DELETE ON schema.t
真正决定空间是否“有效管理”的，从来不是删没删干净，而是删完之后 Oracle 还认不认那些块为空——TRUNCATE 让数据库彻底失忆，DELETE 则留下满地狼藉等着你手动收拾。
