TRUNCATE批量清空表比导出导入快得多，因其是DDL操作、不走回滚段、不触发触发器、秒级完成；而expdp/impdp需读写磁盘、解析元数据、重建对象，耗时长且易中断。
TRUNCATE 批量清空表比导出导入快得多
直接对表执行 truncate table 是清空表空间中所有表数据最快的方式，不需要导出（expdp）、删除、再导入（impdp）这种重操作。导出导入本质是重建对象，耗时长、占临时空间、还可能因权限或路径问题中断。
真正需要导出导入的场景只有一种：你不仅要清空数据，还要把表结构、索引、约束、权限等全部还原到初始状态，且原库无法直连或已损坏。否则纯属绕路。
-
TRUNCATE是 DDL，不走回滚段，不触发触发器，秒级完成百万级行数清空 - 导出导入过程要读写磁盘、解析元数据、重建段，单张大表就可能花几十分钟
- 如果表空间里有 50 张表，
TRUNCATE写个简单 PL/SQL 循环就能搞定；而 expdp/impdp 要反复配置参数、检查日志、处理失败项
用 PL/SQL 批量 TRUNCATE 表空间内所有表
不能直接 TRUNCATE 整个表空间，但可以遍历该表空间下的所有用户表并逐个清空。注意：必须用表所有者或具备 DELETE ANY TABLE 和 ALTER ANY TABLE 权限的用户执行。
以下语句生成并执行批量 TRUNCATE 命令：
BEGIN
FOR t IN (SELECT table_name FROM user_tables WHERE tablespace_name = 'YOUR_TS_NAME') LOOP
EXECUTE IMMEDIATE 'TRUNCATE TABLE ' || t.table_name;
END LOOP;
END;
常见坑点：
- 表名大小写敏感：若建表时用了双引号（如
"MyTable"），查询user_tables.table_name返回的是带引号的名称，直接拼接会报错 —— 建议统一用大写建表，避免此问题 - 外键约束阻断：如果表被其他表外键引用，
TRUNCATE会失败。需先禁用约束：ALTER TABLE child_table DISABLE CONSTRAINT fk_name;，清空后再启用 - 不释放高水位线（HWM）？默认
TRUNCATE已带DROP STORAGE，但若曾显式指定REUSE STORAGE，则需加REUSE STORAGE参数手动控制
删除整个表空间前必须确认无依赖对象
想“清空表空间”，最彻底的方式其实是删掉整个表空间，但前提是它真的空了 —— 不只是没数据，而是连表、索引、LOB 段、物化视图日志等对象都不存在。
检查命令：
SELECT segment_type, COUNT(*) FROM dba_segments WHERE tablespace_name = 'YOUR_TS_NAME' GROUP BY segment_type;
若返回任何记录，说明还有对象残留。此时不能直接 DROP TABLESPACE，否则报错 ORA-01549 或 ORA-01553。
安全删除步骤：
- 先清空所有表：
TRUNCATE或DROP掉表（注意顺序，先子表后父表） - 删索引、约束、LOB 段等附属对象（
dba_indexes、dba_constraints可查） - 确认
dba_segments为空后，执行：DROP TABLESPACE your_ts_name INCLUDING CONTENTS AND DATAFILES; - 注意：该命令会物理删除
.dbf文件，不可逆 —— 别在生产环境手抖复制粘贴就跑
为什么不用 expdp/impdp 清空表空间
导出导入不是清空手段，而是迁移或重建手段。把它当清空方案，等于用卡车运一滴水。
典型问题包括：
-
expdp会锁表、阻塞业务写入，尤其对大表可能锁数小时 - 导出文件体积巨大（即使数据已删，段未 shrink，仍按原大小导出）
- 导入时若目标表已存在，默认报错；设
TABLE_EXISTS_ACTION=TRUNCATE虽可覆盖，但仍是先删约束、再插数据，比原生TRUNCATE慢一个数量级 - 权限链复杂：需要
EXP_FULL_DATABASE、IMP_FULL_DATABASE，很多生产库禁止授予
真正要保留结构又清空数据，就老实用 TRUNCATE；真要重建整个环境，才轮到 expdp/impdp 上场 —— 别混淆目的和工具。
