drop/create 比 truncate 更易产生表空间碎片，因前者彻底释放并离散分配 extent，无法合并小空闲区；后者仅重置 hwm 并可复用原有空间。
频繁 DROP / CREATE 表会快速制造表空间级碎片，核心原因是区（extent）反复分配与释放后无法合并，尤其在 MSSM 表空间中更明显；ASSM 虽缓解争用，但位图块本身也加剧小碎片累积。
为什么 DROP + CREATE 比 TRUNCATE 更容易碎
每次 DROP TABLE 会立即释放该表所有 extent，但 Oracle 不会自动合并相邻空闲 extent —— 尤其当这些空闲区大小不一、或被其他对象“插花”占用时，就形成大量不可用于大对象分配的小碎片。而 CREATE TABLE 又总是尝试按 INITIAL 和 NEXT 参数申请新 extent，进一步打散空间布局。
-
TRUNCATE TABLE只重置高水位线（HWM），保留段结构和大部分 extent，空间仍连续可复用 -
DROP TABLE彻底移除段头块和所有 extent，释放动作是“离散式”的，极易留下 64KB、128KB 等零碎空闲区 - 若表空间使用 MSSM，
PCTUSED和空闲列表（freelist）管理机制会让小碎片长期滞留，无法进入可分配队列
替代方案：用 TRUNCATE + REUSE STORAGE 更安全
只要逻辑上允许清空而非删除表结构，优先用 TRUNCATE 替代 DROP/CREATE，并显式控制存储复用行为：
- 保持原 extent 不释放：
TRUNCATE TABLE t1 REUSE STORAGE—— HWM 下降，但所有已分配 extent 保留在段内，后续 INSERT 可直接复用 - 彻底释放空间给表空间（慎用）：
TRUNCATE TABLE t1 DROP STORAGE—— 效果接近DROP+CREATE，仅在确认无复用需求时选 - 配合
ALTER TABLE ... MOVE整理行数据物理位置，再TRUNCATE ... REUSE STORAGE，能消除行迁移带来的块内碎片
建表时就规避碎片风险
如果业务确实必须周期性重建表（如 ETL 中间表），从源头控制参数比事后清理更有效：
- 统一设置合理的
INITIAL和NEXT，避免默认的 64KB 小 extent 堆积；例如：STORAGE (INITIAL 1M NEXT 1M) - 启用 ASSM 表空间（
SEGMENT SPACE MANAGEMENT AUTO），它用位图管理空闲空间，对小碎片容忍度更高，且无 freelist 争用 - 禁用
LOGGING（如可接受归档日志缺失）：CREATE TABLE t1 NOLOGGING，减少 redo 压力，间接降低因日志写满触发的异常中断导致的段残留 - 避免在 SYSTEM 或 SYSAUX 表空间建临时表——它们强制 MSSM，且无法修改，碎片一旦产生极难清理
真要 DROP，至少加 PURGE 并检查回收站
DROP TABLE t1 默认进回收站（RECYCLEBIN），不仅不释放空间，还让段名变成系统生成的乱码，后续 CREATE 可能因同名冲突或隐式 purge 失败而卡住：
- 强制立即释放：
DROP TABLE t1 PURGE，跳过回收站，减少中间状态干扰 - 查残留：
SELECT object_name, original_name FROM dba_recyclebin WHERE owner = 'SCOTT'，确认无遗漏 - 清空回收站：
PURGE RECYCLEBIN或PURGE DBA_RECYCLEBIN（需权限），防止回收站自身膨胀占空间
真正难处理的不是单次 DROP，而是脚本里循环执行 DROP/CREATE 却没配 PURGE、也没设统一 storage 参数——这种组合会在几天内把一个 10GB 表空间切成上百个无法分配的 64KB 碎片块。监控时看 DBA_FREE_SPACE 总空闲量很充裕，但实际 CREATE TABLE 却报 ORA-01652: unable to extend temp segment，就是典型症状。
