重建索引后dba_segments空间增长并非统计延迟，而是因REBUILD默认继承原索引pctfree值导致叶子块填充率降低；需显式指定合理pctfree并等待SMON清理旧段。
重建索引后dba_segments显示空间增长，不是统计延迟导致的
oracle 重建索引（如 alter index ... rebuild）后，dba_segments.bytes 或 dba_indexes.leaf_blocks 明显变大，常见误判是“统计没刷新”。但执行 dbms_stats.gather_index_stats 后数值不变，说明真实物理空间确实增加了——根本原因在重建时默认沿用原索引的 pctfree 值，而该值可能远高于当前数据密度所需。
PCTFREE 在索引重建时的继承逻辑与隐式放大效应
索引的 pctfree 并非仅用于预留更新空间，它直接决定每个叶子块中允许填充的数据比例。重建时若未显式指定 pctfree，Oracle 会从原索引定义中读取该值（可通过 dba_indexes.pct_free 查看），哪怕原值是为高频更新场景设置的 40%，而当前索引已是只读或极少更新的报表索引，仍会被强制应用。
- 例如原索引
pctfree=30，意味着每个叶子块最多填 70%；重建后即使数据总量不变，块数也会比pctfree=10时多出约 25%～30% -
CREATE INDEX默认pctfree=10，但REBUILD不重置为默认，这是关键差异 - 对 B-Tree 索引，
pctfree影响的是叶子块（leaf block）的填充率，非分支块（branch block）不受影响
如何验证并安全调整重建时的PCTFREE
先确认当前索引的 pctfree 和实际填充率：
SELECT index_name, pct_free, leaf_blocks, distinct_keys, clustering_factor FROM dba_indexes WHERE index_name = 'YOUR_IDX';
再用 ANALYZE INDEX ... VALIDATE STRUCTURE 获取详细块级统计（注意：该命令需排他锁，生产慎用）；观察 opt_cmpr_count 和 del_lf_rows_len / lf_rows_len 比值，若删除行占比低、压缩建议值明显小于当前 pctfree，就说明过度预留。
- 重建时显式指定合理值：
ALTER INDEX your_idx REBUILD PCTFREE 5; - 对只读历史索引，
PCTFREE 0可接受（但需确保未来无 DML） - 若索引含大量重复键值，配合
COMPRESS可进一步减少块数，但COMPRESS本身会略微增加单块开销
重建后空间未释放的其他干扰因素
即使 pctfree 设置合理，仍可能观察到段大小未下降，需排查：
- 索引所在表空间是
ASSM（自动段空间管理）时，高水位线（HWM）不会因重建自动回落；需后续执行ALTER INDEX ... SHRINK SPACE COMPACT（要求启用行移动） - 如果重建使用了
ONLINE选项，临时段和日志开销可能导致短暂空间峰值，但最终段大小应反映新pctfree -
db_block_size和索引键长度影响单块容量，长键 + 小块尺寸下，pctfree的边际效应会被放大
真正容易被忽略的是：重建操作本身不移动旧段，而是分配新段、交换指针、再异步清理旧段。这个清理由 SMON 进程触发，可能延迟数分钟——所以刚重建完立刻查 dba_segments，看到的是“新段+旧段”双存状态，不是最终结果。
