如何在Oracle 12c中采用分区策略缓解高并发下的序列争用

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 获取锁仍会成为新瓶颈。