lob索引段持续增长的根因是basicfile lob物理结构缺陷，其索引段仅增不删，删除lob后指针不回收，需重建索引或迁移到securefile；导出中断残留的sys_export_schema%临时表lob索引段也需直接purge清理。
LOB索引段持续增长的根因是BasicFile LOB的物理结构缺陷
Oracle中所谓“LOB索引段”（SYS_IL*开头的INDEX类型段）本身不存数据，它只是BasicFile LOB的块地址映射表。只要LOB列启用ENABLE STORAGE IN ROW以外的存储方式（即默认配置），每次插入/更新LOB值，就会往这个索引段里写入新的块指针条目；而删除或清空LOB时，这些指针不会自动回收——它们会一直留在索引段里，直到你显式重建该索引。
这和普通B树索引不同：普通索引条目随DML实时增删，LOB索引段却只增不删，长期积累就表现为“持续增长”。SecureFile LOB没有这个索引段，所以不存在该问题。
怎么确认是不是LOB索引段在涨
别直接查dba_segments按名字猜，先定位到具体LOB列：
- 查出占用大的LOB段名：
SELECT owner, segment_name, segment_type, bytes FROM dba_segments WHERE segment_type = 'LOBINDEX' ORDER BY bytes DESC - 反查它归属哪张表：
SELECT owner, table_name, column_name FROM dba_lobs WHERE segment_name = 'SYS_IL0000123456C00003$$' - 确认LOB类型：
SELECT securefile FROM dba_lobs WHERE segment_name = 'SYS_IL0000123456C00003$$'—— 返回NO就是BasicFile，必须处理；返回YES则说明是SecureFile，这个段不该存在，可能是迁移残留或元数据损坏
重建LOB索引前必须先MOVE表（BasicFile场景）
对BasicFile LOB，单独ALTER INDEX ... REBUILD没用——重建后增长还会继续。真正有效的路径是：
-
ALTER TABLE owner.table_name MOVE LOB(lob_column) STORE AS (TABLESPACE new_ts ENABLE STORAGE IN ROW)或更推荐：STORE AS (SECUREFILE) - MOVE后，原
SYS_IL*索引段会被自动丢弃，新段（如果是SecureFile）根本不会生成 - MOVE操作会重建底层LOB段+LOB索引段，但只在事务提交后才生效，期间表可读不可写
- MOVE前必须确保表已启用行移动：
ALTER TABLE owner.table_name ENABLE ROW MOVEMENT - MOVE后记得重建普通索引：
ALTER INDEX owner.idx_name REBUILD ONLINE，否则查询主键可能失败
最容易被忽略的陷阱：导出中断残留的SYS_EXPORT_SCHEMA% LOB
很多“持续增长”的LOB索引段其实不属于业务表，而是SYS_EXPORT_SCHEMA_01这类临时表——它们是Data Pump导出中断后遗留的未清理对象。这类对象的LOB索引段不会随业务DML变化，但会一直占着空间。
验证方法：SELECT * FROM dba_tables WHERE table_name LIKE 'SYS_EXPORT_SCHEMA%'，如果LAST_ANALYZED时间集中在某次备份失败时段，基本可锁定。
清理方式不是重建索引，而是直接删表：DROP TABLE owner.SYS_EXPORT_SCHEMA_01 PURGE。注意加PURGE，否则进回收站仍占空间。
SecureFile迁移、MOVE表、清理残留——三者逻辑不同，混用会白忙。先分清对象归属，再选路径。
