根本原因是单调递增主键导致所有插入集中于同一索引叶块，rac多实例反复争抢该块，引发高频gc buffer busy acquire和tx锁冲突；reverse key索引可将序列值反转散列写入，缓解热块争用。
为什么RAC里索引叶块会成为性能瓶颈
根本原因不是索引本身慢，而是单调递增的主键（比如 SEQUENCE.NEXTVAL）导致所有新插入都挤在同一个索引叶块右侧——这个块在RAC中被多个实例反复争抢，触发高频 gc buffer busy acquire 和 enq: TX - row lock contention。AWR里看到这两个事件飙升，基本可以锁定是索引热块。
用REVERSE KEY索引快速破局
对纯等值查询（WHERE id = ?）且不依赖范围扫描的场景，REVERSE KEY 是最直接的缓解手段：它把 10001、10002、10003 这类序列值反转成 10001、20001、30001，让物理插入位置随机散列到不同叶块上。
- 创建命令必须显式指定
REVERSE：CREATE INDEX idx_orders_id_rev ON orders(order_id) REVERSE; - 不能用于
WHERE order_id > 10000这类范围查询——反转后顺序已乱，优化器会放弃走索引 - 重建时需注意：原索引若含
UNIQUE约束，REVERSE后仍保持唯一性，但约束名需手动重建
替代方案：哈希扰动 + 分区分散压力
当业务需要保留范围查询能力，或表已是分区表时，避免单点索引前导列更稳妥：
- 在主键生成逻辑里加扰动，例如用
MOD(id, 16)作为分区键，再配合本地分区索引，把写入打散到16个子段 - 将单调字段（如
created_date）从索引前导列挪到非前导位置，改用高选择性列（如tenant_id）做前导 - 确认表启用了
ASSM（自动段空间管理）：SELECT segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'USERS';返回AUTO才有效；手工FREELISTS在RAC中会加剧争用
容易被忽略的隐性陷阱
即使加了 REVERSE 或分区，如果底层 sequence 没配好，争用只是转移而非消失：
- 检查
sequence是否启用CACHE：SELECT sequence_name, cache_size, order_flag FROM dba_sequences WHERE sequence_name = 'SEQ_ORDERS';—— 若cache_size为 1 或order_flag为Y，立刻改成CACHE 1000 NOORDER -
gc current block busy高时，别只盯着索引段，用p1/p2反查对象，可能是 undo 段争用（说明事务太长或UNDO_RETENTION不合理） - RAC中每个实例必须独占 undo 表空间，
SHOW PARAMETER undo_tablespace必须返回不同值（如UNDOTBS1、UNDOTBS2），共用会引发ORA-01555
