assm本身不引发索引分裂，但会放大50-50分裂频率与块争用；真正触发分裂的是insert等dml操作，assm因位图管理导致多会话争抢同一叶块，加剧分裂和enq: tx等待。
自动段空间管理（ASSM）本身不引起索引分裂，但会放大分裂频率和竞争
ASSM 不是索引分裂的触发原因，它只是改变了空闲空间的管理方式。真正触发 leaf node split 的永远是 DML 操作（尤其是 INSERT）导致索引块无足够空间容纳新键值。ASSM 的影响在于：它用位图替代了 freelists，使得多个会话更可能同时选中同一个“看似有空”的叶块——结果争抢同一块、频繁触发 50-50 split，而不是有序地往右追加。
常见错误现象包括：enq: TX - index contention 等待陡增、v$sysstat 中 leaf node 50-50 splits 计数远高于 leaf node 90-10 splits、AWR 报告里 “Index Block Reorganizations” 高于预期。
- ASSM 下没有 freelists 争用，但位图更新有 latch 开销；当并发 INSERT 随机键值时，多个进程可能从同一 bitmapped block 获取 ITL 槽或插入位置，加剧块内空间碎片化
- 90-10 分裂倾向递增键（如序列、时间戳），而 ASSM 并不阻止这种模式；但如果业务用 UUID 或打乱的 ID，ASSM 反而让 50-50 分裂更难避免
- ASSM 表空间中，
PCTFREE对索引块的实际保留效果变弱——位图只标记“块是否可插入”，不精确反映剩余字节，导致块在逻辑上“还有空”但物理上无法塞入新索引条目
怎么判断是不是 ASSM 导致分裂异常增多
先确认索引所在表空间确实是 ASSM：
SELECT tablespace_name, segment_space_management FROM dba_tablespaces WHERE tablespace_name = (SELECT tablespace_name FROM dba_indexes WHERE index_name = 'YOUR_IDX');
再比对关键指标：
- 查
v$sysstat：如果leaf node 50-50 splits/leaf node splits> 0.7，且业务并非高并发随机写，就要怀疑 ASSM + 低PCTFREE组合 - 查
dba_indexes的pct_free：索引默认PCTFREE是 10，但 ASSM 下若设为 0 或 5，极易诱发分裂；建议 OLTP 场景下保持 ≥15 - 用
DBMS_SPACE.SPACE_USAGE检查具体索引段的块使用率分布，看是否大量叶块处于 “75–95% full” 区间（最易分裂临界区）
ASSM 下降低叶节点分裂的有效手段
不能关 ASSM（19c 默认且不可退），只能调优行为：
- 对高频随机插入的索引，显式增大
PCTFREE：ALTER INDEX your_idx REBUILD PCTFREE 20;注意：重建后需收集统计信息，否则优化器可能误判选择性 - 避免在 ASSM 表空间中创建低基数、高更新率的复合索引——这类索引叶块极易因 ITL 槽不足触发 50-50 分裂
- 监控
v$segment_statistics中gc cr block busy和gc current block busy，若与分裂高峰重叠，说明 RAC 环境下跨实例块争用被 ASSM 放大 - 对纯递增键场景（如订单号+时间戳），确保应用端批量插入按顺序提交，减少同一块内多事务未提交造成的分裂降级（本该 90-10 却被迫 50-50）
容易被忽略的关键点
ASSM 和索引分裂的关联性常被高估，但真正致命的是组合条件：低 PCTFREE + 随机键 + 高并发 + 未提交事务共存于同一叶块。单独任何一个因素都不足以造成严重抖动。另外，DBMS_AUTO_INDEX 创建的自动索引默认继承表空间的 ASSM 属性，且不支持指定 PCTFREE，这意味着自动索引在 ASSM 表空间中天生更容易分裂——这点在启用自动索引前极少被评估。
