建表时必须显式声明SECUREFILE并配置COMPRESS HIGH、DEDUPLICATE ENABLE和STORAGE IN ROW；DELETE后需执行MOVE LOB + MODIFY LOB SHRINK SPACE才能释放空间；监控应查dba_segments而非dba_tables。
建表时就该强制启用SecureFile + COMPRESS + DEDUPLICATE
BasicFile是Oracle旧式LOB存储，默认不压缩、不去重，哪怕两行CLOB内容完全一样，也会各自存一份；改一个字节就写新块，旧块滞留。SecureFile才是现代LOB的正确起点，但必须显式声明，否则新建表仍走BasicFile路径。
-
CREATE TABLE语句中必须包含LOB (col) STORE AS SECUREFILE，不能只写LOB (col) - 关键参数要一步配齐：
COMPRESS HIGH DEDUPLICATE ENABLE STORAGE IN ROW——STORAGE IN ROW对小LOB（≤4000字节）能省掉一次指针跳转，COMPRESS HIGH和DEDUPLICATE ENABLE才真正抑制膨胀 - 别信“默认开启”：12c+虽默认创建SecureFile，但
compression默认是NONE，deduplication默认是DISABLE，查dba_lobs.compression和deduplication字段才能确认
DELETE后必须MOVE + SHRINK，不能只靠TRUNCATE或DROP
LOB字段所在的行被DELETE，只是逻辑标记删除，对应LOB段里的数据块不会释放；TRUNCATE TABLE 虽清空表段，但LOB段和LOBINDEX段仍原封不动留在原地——它们是独立段，不受TRUNCATE影响。
- 删完大量数据后，必须立刻执行：
ALTER TABLE t MOVE LOB(col) STORE AS (TABLESPACE new_ts)，把LOB段物理迁移并重建 - MOVE之后补上：
ALTER TABLE t MODIFY LOB(col) (SHRINK SPACE)，这步才真正下移LOB段高水位线（HWM） - 漏掉
MODIFY LOB ... SHRINK SPACE，dba_segments.bytes就不会下降，空间白删
监控LOB段占比，别只看dba_tables.blocks
用SELECT * FROM dba_tables估算表大小，会严重低估真实占用——它不统计LOB段、LOBINDEX段、本地索引段。一张几万行的表，若含CLOB字段，实际空间可能是dba_tables.blocks显示值的10倍以上。
- 真空间大户藏在
dba_segments里：按segment_type IN ('TABLE', 'INDEX', 'LOBSEGMENT', 'LOBINDEX')分组查bytes，再关联dba_lobs定位具体哪个字段拖累最狠 - 快速定位LOB膨胀源：
SELECT owner, table_name, column_name, segment_name, bytes/1024/1024 mb FROM dba_lobs l JOIN dba_segments s ON l.segment_name = s.segment_name WHERE s.bytes > 100*1024*1024 ORDER BY s.bytes DESC - 发现某CLOB字段对应LOB段占80GB？别急着删数据，先查
dba_lobs.deduplication是不是DISABLE、compression是不是NONE
避免CHUNK过大或过小，合理设置读写粒度
LOB的CHUNK是I/O最小单位，默认等于DB_BLOCK_SIZE（通常8KB）。存100字节也要占一个CHUNK，频繁追加小片段会迅速制造大量低利用率CHUNK，且LOBINDEX随之线性膨胀。
- 对日志类追加型CLOB（如每次
DBMS_LOB.WRITEAPPEND写几百字节），建议CHUNK 2048或4096，平衡碎片与元数据开销 - 对整存整取型BLOB（如PDF文件），可保持默认8KB，但务必配合
COMPRESS HIGH，否则单个文件就撑爆表空间 -
CHUNK一旦设定无法ALTER修改，只能MOVE重建，所以建表时就得想清楚
真正卡住空间回收的，从来不是数据量本身，而是LOB段的独立生命周期和默认保守策略。MOVE和SHRINK必须成对出现，而COMPRESS+DEDUPLICATE不是锦上添花的选项，是防止空间失控的底线配置。
