REBUILD后空间未降，因默认继承旧PCTFREE和STORAGE参数、旧段未被SMON及时清理、ASSM下HWM不回落，且未更新统计信息；需显式指定PCTFREE/STORAGE、等待SMON清理或DROP SEGMENT、结合SHRINK或重建表空间释放空间。
重建后空间没下降，不是操作失败，而是你没踩中真正释放空间的关键点——REBUILD本身能重排结构，但默认行为会继承旧参数、不清理旧段、不降高水位线（HWM），甚至可能把索引建到错误位置。
为什么REBUILD后DBA_SEGMENTS.BYTES几乎不变
常见错觉是“重建=瘦身”，但Oracle的REBUILD只是新建一棵B树，旧段仍保留在数据字典中，直到SMON进程异步清理。这期间DBA_SEGMENTS统计的就是新旧两段之和。
- 执行
ALTER INDEX idx REBUILD后立即查DBA_SEGMENTS，看到的是新段+未清理的旧段 - 等几分钟再查，或手动触发
EXEC DBMS_SPACE_ADMIN.SEGMENT_CORRUPT_MARK（不推荐）无效；正确做法是等SMON自动回收，或确认旧段已无引用后用DROP SEGMENT（仅限12c+且有权限） - 更直接验证方式：查
DBA_EXTENTS，看是否新增了大量extent，且旧extent仍存在
PCTFREE被悄悄继承，导致新索引更“松散”
重建不重置PCTFREE，它从原索引定义里读取——哪怕原值是为高频更新设的40%，而你现在重建的是只读报表索引，结果新叶子块填充率只有60%。
- 查当前值：
SELECT index_name, pct_free FROM dba_indexes WHERE index_name = 'YOUR_IDX' - 若返回
PCTFREE = 30，重建时必须显式覆盖：ALTER INDEX your_idx REBUILD PCTFREE 5 - B-Tree索引
PCTFREE = 0在只读场景下安全，但位图索引才真正适合设为0；B-Tree设0后未来任何DML都可能引发分裂
导入数据带来的STORAGE参数陷阱
如果你的索引来自EXP/IMP或Data Pump导入，原始INITIAL大小（比如337MB）会被完整继承。重建时不显式覆盖STORAGE，新索引照样按337MB起建。
- 典型症状：表只有2行，索引却占13GB——
INITIAL过大 +NEXT不合理 - 重建时必须带完整
STORAGE子句：ALTER INDEX idx REBUILD STORAGE (INITIAL 64K NEXT 1M) - 导出时加
COMPRESS=N（注意：不是压缩数据，而是禁用“初始区合并”逻辑），可避免导入时放大INITIAL
ASSM表空间下HWM不回落，空间无法返还给文件系统
即使新索引物理块数少了，只要所在表空间是ASSM（自动段空间管理），高水位线（HWM）不会因REBUILD自动下降——DBA_FREE_SPACE里看不到空闲空间增加，DATAFILE也无法RESIZE缩小。
- 验证是否ASSM：
SELECT segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TBS'，返回AUTO即为ASSM - 对B-Tree索引，
SHRINK SPACE不支持；唯一办法是REBUILD后，用ALTER TABLESPACE ... COALESCE尝试合并空闲extents（效果有限） - 真要缩文件，只能导出→重建表空间→导入；或升级到12c+用
ALTER DATABASE DATAFILE ... RESIZE（需先确保HWM已实际下降）
最常被忽略的一点：重建后不收集统计信息，CBO可能继续按旧LEAF_BLOCKS估算成本，导致执行计划劣化——看起来“空间没省”，其实是查询变慢让你误判效果。别跳过DBMS_STATS.GATHER_INDEX_STATS。
