oracle 12c高并发序列争用本质是单调递增索引叶块热争用，唯一结构化解法是对索引做global hash分区，如create index idx_id_hash on t(id) global partition by hash(id) partitions 8；反向键索引仅支持等值查询且大表性能差，而hash分区支持全类型查询且写入均匀分散。
oracle 12c 中高并发下的序列争用（enq: tx - row lock contention 或 gc buffer busy acquire）本质是多个会话集中写入索引叶块，尤其是单调递增的 sequence.nextval 导致的热块问题。单纯调大 cache 或换 noorder 只缓解表层症状，真正有效的解法是让写入分散到多个物理索引块——分区是唯一能从结构上破局的手段。
为什么 hash 分区比反向键索引更可靠
反向键索引（REVERSE KEY）虽能打散叶块访问，但只支持等值查询，一旦业务含 BETWEEN、> 或分页排序，执行计划立即退化；且大表上响应时间明显变长。hash 分区则无此限制：它把索引按哈希值拆成多个独立段，每个段有自己的高水位线和空闲空间管理，天然支持所有查询类型。
- 必须对索引本身做 hash 分区（不是表），语法为：
CREATE INDEX idx_id_hash ON t(id) GLOBAL PARTITION BY HASH(id) PARTITIONS 8 - 分区数建议设为并发写入实例数 × 4（如 RAC 2 节点，选 8；单实例高并发可设 16）
- 不能对主键约束直接建 hash 分区索引——需先禁用约束，建索引后再重建约束
- 本地索引不适用：hash 分区索引必须是
GLOBAL，否则无法保证唯一性
如何用 smart index 避免改索引结构
若无法修改索引或表结构（如第三方系统），可在应用层构造“带扰动的 ID”，让序列值不再单调递增，从而自然分流写入热点。这不是绕过问题，而是从源头切断争用路径。
- 典型实现：
prefix1 := 1E23 * USERENV('INSTANCE');+prefix2 := 1E20 * MOD(USERENV('SID'), 100);+seq.nextval - 前缀确保不同 RAC 实例写入完全不同的索引范围，
SID模运算进一步在单实例内分 100 个槽位 - 注意 sequence 最大值不能超
10^19-1，否则加前缀后溢出（NUMBER精度上限为 38 位） - 该方案对 SQL 完全透明，无需改索引，但要求业务能接受 ID 不再严格递增
interval 分区表配合序列时的陷阱
很多人误以为 interval 分区能自动解决序列争用，其实不然——interval 控制的是数据按时间落哪个分区，而索引争用发生在索引段内部，与表分区无关。除非你同时对索引做 hash 分区，否则只是把热块从一个段转移到另一个段。
- 如果表按
cngr_SEMReleaseTime做 interval 分区，但主键索引仍是 B-tree 单段，争用照旧 - 想真正分流，必须让索引也分区：要么全局 hash 分区，要么将主键字段加入分区键（如
PARTITION BY HASH(id, cngr_SEMReleaseTime)） - interval 分区本身会因自动建分区触发
enq: HW - contention，此时要预建未来 6–12 个月的分区（如p_202701），避免运行时争抢高水位线
最易被忽略的一点：无论用哪种方案，都必须确认 UNDO_TABLESPACE 是每个实例独占的，且 sequence 已启用 CACHE 1000 NOORDER。否则即使索引分散了，undo 段争用或 sequence 获取锁仍会成为新瓶颈。
