lob段空间不会随delete或truncate自动释放，必须根据lob类型选择alter table modify lob shrink space（securefile）或alter table move lob store as securefile（basicfile），否则无效。
LOB段空间不会随DELETE或TRUNCATE自动释放，必须用ALTER TABLE MODIFY LOB收缩或ALTER TABLE MOVE重建——但两者适用条件完全不同，选错就白跑。
查清LOB类型再动手：BasicFile还是SecureFile？
很多人一上来就MOVE或SHRINK，结果发现没效果，根源是没确认当前LOB类型。SecureFile默认支持压缩和去重，BasicFile则几乎不回收空间。
- 执行
SELECT table_name, column_name, securefile FROM dba_lobs WHERE owner = 'YOUR_SCHEMA' AND table_name = 'YOUR_TABLE'，看securefile字段值 -
YES→ 已是SecureFile，优先考虑SHRINK SPACE（需ASSM表空间+启用行移动） -
NO→ BasicFile，SHRINK无效，必须MOVE并显式指定STORE AS SECUREFILE - 查不到记录 → 该LOB列启用了
STORAGE IN ROW，数据内联在表段里，不占独立SYS_LOB*$$段，无需单独处理
BasicFile必须用ALTER TABLE MOVE带LOB子句
ALTER TABLE t MOVE本身只搬主表堆段，SYS_LOB*$$段完全不动——这是最常踩的坑。不加LOB (col) STORE AS，等于白干。
- 目标表空间必须是ASSM：
SEGMENT SPACE MANAGEMENT AUTO，否则报ORA-43853 - 语法必须完整：
ALTER TABLE your_schema.your_table MOVE TABLESPACE ts_lob_new LOB (content) STORE AS SECUREFILE (COMPRESS HIGH DEDUPLICATE) - MOVE后所有索引（含主键、唯一约束生成的）状态变为
UNUSABLE，必须逐个ALTER INDEX idx_name REBUILD ONLINE - 分区表要对每个分区单独写
MOVE PARTITION p_name LOB (col) STORE AS ...，不能只写表级
SecureFile用ALTER TABLE MODIFY LOB (...) SHRINK SPACE
对已启用SecureFile的LOB，SHRINK SPACE比MOVE更轻量、更安全，它在线清理碎片、下移HWM，且自动维护LOB index。
- 前提：先执行
ALTER TABLE t ENABLE ROW MOVEMENT - 核心命令：
ALTER TABLE t MODIFY LOB (clob_col) (SHRINK SPACE CASCADE)（注意括号嵌套） - 若没效果，检查三点：
dba_segments中该LOB段是否真有空闲块；表空间是否ASSM；是否有长事务正访问该LOB列 -
SHRINK不支持BasicFile，也不支持SECUREFILE的COMPRESS属性变更——想加压缩，只能MOVE
紧急场景下TRUNCATE或重建LOB列
当SHRINK卡住、MOVE不可行，或业务允许短时中断时，可走激进路径。
- 整表可清空：
TRUNCATE TABLE t REUSE STORAGE，LOB段立即重置，空间秒退 - 只想删LOB列：
ALTER TABLE t DROP COLUMN clob_col，但会锁表且无法回滚；更稳妥是建临时表CREATE TABLE t_temp AS SELECT col1, col2 FROM t，再交换表名 - 回收站里残留的
SYS_LOB*$$对象，用DROP TABLE RECYCLEBIN或PURGE RECYCLEBIN清理 - 导出导入后空间暴增，大概率是
expdp没加TRANSFORM=SEGMENT_ATTRIBUTES:n，导致LOB属性丢失
真正占用空间的从来不是LOB数据本身，而是未被清理的旧版本块、低效CHUNK分配、失效的LOB index，以及误判类型后反复执行却无果的操作。动手前务必先查dba_lobs.securefile和dba_segments.segment_name，不然再快的命令也是往空桶里灌水。
