是的，truncate后表占用的extents立即被标记为“未使用”可被复用，但数据文件物理大小不变，操作系统层面空间不回收；需额外执行resize才能缩小文件，且前提为文件末尾全空。
是的，TRUNCATE 后表占用的 extents 立即被标记为“未使用”，可被其他对象复用；但数据文件（datafile）物理大小不会缩小，也不等于操作系统层面的空间回收。
TRUNCATE 为什么能立即释放逻辑空间
TRUNCATE 是 DDL 操作，直接修改数据字典和区（extent）位图，把原分配的所有 extents 标记为“空闲”。执行后查 DBA_EXTENTS，该表对应的记录数会大幅减少（只剩 MINEXTENTS 个，通常为 1）。这意味着：这些空间已脱离该表管辖，同一表空间内新建表、索引或插入数据时，会优先复用这部分 extent。
- 不依赖 COMMIT：执行即生效，不可回滚
- 不写行级 undo/redo：比 DELETE 快得多，尤其大表
- 重置高水位线（HWM）：后续全表扫描跳过大量空块，性能提升明显
- 默认行为就是
DROP STORAGE；加REUSE STORAGE才保留原 extent 分配（极少用）
为什么 df -h 看不到磁盘空间变大
Oracle 的“释放空间”指释放 segment 级别的逻辑存储单元（extents），不是收缩数据文件。数据文件本身仍占据原有物理大小，OS 层看不到变化。
-
TRUNCATE不动DBA_DATA_FILES中的BYTES字段 - 想缩小数据文件，得额外执行
ALTER DATABASE DATAFILE 'xxx.dbf' RESIZE xxxM - 但 resize 前必须确保文件末尾全是空闲 extent，否则报错 ORA-03297
- LOB 段可能残留：若表含 LOB 字段且未指定
INCLUDING DATA，需单独检查DBA_LOBS并处理
TRUNCATE 后空间没被复用？先查这三件事
有时你清空了表，却发现新表还是分配了新 extent，老空间“没被用起来”，常见原因：
- 表空间是
DICTIONARY-MANAGED（字典管理）：TRUNCATE 在这类表空间中行为受限，推荐迁移到LOCAL-MANAGED - 存在未提交事务或锁：其他会话正在查询该表，或持有 DML 锁，影响 extent 重用判定
- 自动段空间管理（ASSM）下，空闲空间可能被 bitmap block 缓存延迟更新，等几分钟再查
DBA_FREE_SPACE更准 - 误用了
TRUNCATE TABLE t REUSE STORAGE：这个子句会让 extents 继续归属该表，只是清空内容——它根本没释放
替代方案：什么时候不该用 TRUNCATE
TRUNCATE 要求整表清空，且有硬性限制，强行用会报错或失效：
- 表被外键引用：报错
ORA-02266，得先禁用或删外键 - 表上有物化视图日志：报错
ORA-02449，得先DROP MATERIALIZED VIEW LOG - 需要保留部分数据：TRUNCATE 不支持 WHERE，语法
TRUNCATE TABLE t WHERE ...直接报错 - 依赖 rowid 的应用逻辑：TRUNCATE 后 rowid 全失效，旧缓存或中间件可能出错
真正容易被忽略的是：TRUNCATE 不清理统计信息，首次查询仍走旧执行计划；而空间是否被复用，关键看 DBA_FREE_SPACE 而不是 DBA_SEGMENTS —— 后者只反映“谁占着”，前者才说明“哪块真空着”。
