truncate 能直接释放表空间，但仅限整表清空；它重置hwm、不走回滚段、不触发触发器，比delete快，但不可带where、可能因依赖报错，且不缩小数据文件物理大小。
truncate 能不能直接释放表空间
能，但只限于整表清空场景。truncate 是 ddl 操作，会隐式提交、重置高水位线（hwm），并立即释放 segment 占用的空间（除非启用了 reuse storage）。它不走回滚段，不触发触发器，也不产生大量 redo —— 所以比 delete 快得多。
但要注意：TRUNCATE TABLE t1 无法加 WHERE 条件；如果表被其他对象（如物化视图日志、外键引用）依赖，可能报错 ORA-02266 或 ORA-02449；执行后原表的统计信息会失效，后续首次查询可能触发硬解析。
- 若需保留部分数据，TRUNCATE 不适用，别硬套
TRUNCATE ... WHERE—— 语法根本不存在 - TRUNCATE 后，
dba_extents中该表对应的 extent 记录会消失，但表空间文件（datafile）本身的物理大小不会缩小 - 如果表带 LOB 字段且未指定
INCLUDING DATA，LOB 段可能残留，需额外检查dba_lobs
SHRINK SPACE 为什么常失败或没效果
SHRINK SPACE 是针对已 DELETE 过数据的表“在线回收空间”的主要手段，但它不是万能的。常见失败原因包括：表上没启用行移动、存在不可收缩的索引组织表（IOT）、有未提交事务、或者表空间是字典管理（非本地管理）。
执行前必须先运行：ALTER TABLE t1 ENABLE ROW MOVEMENT。否则报错 ORA-10636: row movement is not enabled。启用后，rowid 可能变化，所以依赖 rowid 的应用逻辑（比如某些旧版中间件缓存）要重新验证。
- SHRINK 分两步：
SHRINK SPACE COMPACT（只整理 HWM 下的数据，不释放空间）和SHRINK SPACE（真正释放并降低 HWM）；后者会阻塞 DML，建议在低峰期执行 - 如果表上有函数索引、域索引（Domain Index）或位图连接索引，
ENABLE ROW MOVEMENT会失败，得先删索引再 shrink，完事再重建 - SHRINK 对分区表只能作用于整个表或单个分区（
SHRINK SPACE PARTITION p1），不能跨分区自动合并空闲区
DELETE 后不 shrink，空间到底去哪了
DELETE 只是把数据行标记为“可覆盖”，HWM 不动，segment 的 extent 仍被占用。查询 dba_segments.bytes 和 dba_extents.blocks 会发现数值不变；但 dba_tab_statistics.num_rows 减少了 —— 这就是“逻辑删 vs 物理占”的典型脱节。
这时候看表空间使用率（查 dba_free_space）可能显示“空闲很多”，但实际新插入数据仍可能触发扩展 datafile，因为 Oracle 默认从 HWM 往上分配新块，而不是优先复用 HWM 下的“空洞”。
- 一个典型误判：用
SELECT SUM(bytes)/1024/1024 FROM dba_free_space看到大量 free space，就以为磁盘够用 —— 其实那些 free space 可能全在 HWM 上方，对当前表无效 - 如果表后续持续 INSERT，Oracle 会在 HWM 上方追加 extent，导致表碎片加剧，甚至触发
ORA-01652（无法扩展 temp segment） - 此时最稳的解法不是 shrink，而是
CREATE TABLE t1_new AS SELECT * FROM t1 WHERE ...+DROP TABLE t1+RENAME，但要求有足够临时空间容纳新表
表空间文件本身怎么缩小
SHRINK SPACE 和 TRUNCATE 都只影响 segment 级空间，不缩减 datafile 物理大小。要真正腾出磁盘，得靠 ALTER DATABASE DATAFILE 'xxx.dbf' RESIZE Nm。
但直接 resize 有风险：如果目标大小小于当前已分配的最高 block，会报 ORA-03297。必须先确认该 datafile 的“实际末尾使用位置”：
SELECT ceil(max_block * block_size / 1024 / 1024) AS "Resize_to_MB" FROM ( SELECT max(block_id) max_block FROM dba_extents WHERE file_id = (SELECT file_id FROM dba_data_files WHERE name LIKE '%xxx.dbf%') ), ( SELECT value block_size FROM v$parameter WHERE name = 'db_block_size' );
- 这个查询结果是该 datafile 当前实际需要的最小 MB 数，resize 值必须 ≥ 它，否则失败
- 如果表空间是 AUTOEXTEND，建议关掉：
ALTER DATABASE DATAFILE 'xxx.dbf' AUTOEXTEND OFF，避免半夜自动撑大又难缩回 - RESIZE 操作本身不锁表，但若涉及移动数据（如 shrink 后立即 resize），底层 IO 压力不小，别在业务高峰期连着做
实际操作中，最易被忽略的是：SHRINK 前忘了检查索引状态，或 TRUNCATE 后没更新统计信息，导致后续执行计划劣化。这两步看着小，却常让 DBA 多花半天排查性能抖动。
