没查到`enq: TX - index contention`就说明没有分裂？

这是个常见的误解。`enq: TX - index contention`这个等待事件，通常只在递增主键这类右侧热点引起的ITL（Interested Transaction List）争用中才会显著出现。许多其他类型的索引分裂操作并不会触发该事件。因此，不能仅凭这个事件的有无来判断分裂是否发生。

为什么`V$ACTIVE_SESSION_HISTORY`查不到最近的分裂线索？

这通常与时间窗口和内存配置有关，具体原因如下： * **查询时间范围不够精确**：ASH默认保留大约1小时的数据，但在高负载场景下，缓冲区很快会被新数据覆盖。如果你没有使用`WHERE sample_time > SYSDATE - 1/1440`来限定最近1分钟的数据，扫描到的很可能已经是旧数据。 * **ASH缓冲区（`_ash_size`）过小**：默认配置通常为4MB，对于生产环境而言往往不够用。你可以通过查询`SELECT * FROM v$sgastat WHERE name LIKE '%ASH%'`来检查，如果`bytes`长期低于10MB，采样丢失的概率会非常高。 * **分裂本身时间极短**：一次典型的90-10分裂可能只持续几毫秒，而ASH每秒才采样一次。这就像用慢速相机去抓拍一个瞬间动作，很容易错过。 遇到这种情况，需要转换思路。可以执行`ANALYZE INDEX ... VALIDATE STRUCTURE`命令来检查`INDEX_STATS`。如果`DEL_LF_ROWS_LEN / LF_ROWS_LEN`的比值超过20%，基本上是分裂后空间未能有效复用的铁证。

怎么把ASH数据和具体的索引精准关联起来？

仅靠`current_obj#`关联出索引名还不够，还需要验证这些会话的访问是否真的落在叶块上。推荐分解步骤： 1. **定位可疑SQL与对象**：先从ASH中找出有问题的`sql_id`，再通过`dba_objects`将其关联到具体的表和索引对象ID。例如，可以执行类似`SELECT object_name, object_type FROM dba_objects WHERE object_id IN (SELECT current_obj# FROM v$active_session_history WHERE sql_id = '...' ...)`的查询。 2. **确认DML活动**：接着检查该索引是否正在被频繁的DML操作访问。查询`dba_indexes`中对应表的`monitoring`字段，如果值为'YES'，说明近期有大量更新活动。 3. **核实执行计划**：最后，查看相关SQL的执行计划，确认是否使用了该索引的`RANGE SCAN`或`FAST FULL SCAN`。同时要特别关注`access_predicates`，判断是否因绑定变量值倾斜导致索引反复分裂。 需要注意的是，ASH中的`sql_id`可能因为SQL被淘汰而不再存在于`V$SQL`中。此时应优先去`DBA_HIST_SQLTEXT`中查找，或者使用12c及以后版本提供的`DBMS_XPLAN.DISPLAY_ASH`工具来还原上下文。

重建索引前，跑个`ALTER INDEX ... COALESCE`够用吗？

`COALESCE`确实有一定作用，但它并非万能，效果有前提条件。它只适用于叶块间虽然有很多删除操作（`DEL_LF_ROWS`很多），但总行数（`LF_ROWS`）不多，且总块数（`BLOCKS`）没有显著增长的情况。它的优点是操作期间不锁整个索引，允许DML继续执行。但缺点也很明显：它无法降低索引的层级（`BLEVEL`），也不能清理枝节点（分支节点）的碎片。 如果从`INDEX_STATS`中看到`BLOCKS`数远大于`LF_BLKS`数，并且`BLKS_GETS_PER_ACCESS`的值大于5，说明索引分裂已经造成物理上的严重离散。此时`COALESCE`效果有限，最终还是需要执行`REBUILD`。 这里有一个经常被忽略的陷阱：重建前，务必确认该索引是否被`DBMS_SCHEDULER`的job或后台批量处理程序频繁调用。这些会话在ASH中通常表现为`program LIKE '%j00%'`。如果未提前停止这些job，`REBUILD`操作很可能因等待`DDL lock`而卡住，同时也会拖慢job的执行。