哈希分区表并发插入慢的根本原因是索引维护开销，而非分区类型本身；唯一或全局索引导致跨分区检查、latch争用和日志激增，应优先使用本地非唯一索引、append直路径插入，并启用parallel dml。
哈希分区表并发插入慢，根本不是分区类型问题
哈希分区本身不导致插入变慢，真正拖慢的是索引维护——尤其是唯一索引或全局索引。oracle 19c 对哈希分区表执行 insert 时，数据会按哈希值自动路由到对应分区，但每条记录仍要同步更新所有相关索引。若存在唯一约束（哪怕建在本地索引上），oracle 必须跨分区做唯一性检查，执行计划里会出现 index range scan + table access by index rowid batched，逻辑读激增。
常见现象包括：enq: TX - index contention 等待事件飙升、log file sync 平均等待时间超过 5ms、AWR 中 “Index Fast Full Scan” 次数异常增长。
- 哈希分区适合写入均衡，但前提是索引设计匹配：本地非唯一索引 + 分区键作为前导列
- 唯一约束必须依赖全局索引，而全局索引在高并发插入下天然成为瓶颈
- 若业务允许容忍短时间唯一性延迟，可改用应用层校验 +
/*+ APPEND */直接路径插入
本地索引 vs 全局索引：并发插入时怎么选
本地索引（LOCAL）在哈希分区表中只影响目标分区，分裂和维护开销可控；全局索引（GLOBAL）则需跨所有分区维护 B-tree 结构，DML 过程中全程参与，性能随数据量线性下降。
特别注意：即使你建的是 LOCAL UNIQUE INDEX，Oracle 仍会隐式触发跨分区检查——因为哈希函数不可逆，无法仅靠单一分区判断全局唯一性。所以实际效果等同于全局索引。
- 高频并发插入场景，优先使用
LOCAL NONUNIQUE INDEX，把唯一性校验移到应用或批量后置校验 - 必须保留唯一约束？改用
GLOBAL HASH INDEX（如UNIQUE (order_id) GLOBAL INDEX HASH PARTITIONS 64），比 B-tree 全局索引减少 latch 争用 - 已有全局索引且不能删？插入前执行
ALTER INDEX idx_name UNUSABLE，插入完再REBUILD，比边插边维护快 3–5 倍
并行 INSERT SELECT 在哈希分区上为何不生效
INSERT /*+ PARALLEL(a,8) APPEND */ INTO t SELECT /*+ PARALLEL(b,8) */ * FROM src 在哈希分区表上容易降级为串行，不是语法错，而是优化器发现无法安全剪枝时主动放弃并行。哈希分区不支持范围裁剪，WHERE 条件若未命中具体分区名，优化器往往不敢并行。
典型失效场景：查询条件含函数（如 WHERE MOD(id, 64) = 1）、或只用非分区键过滤、或没指定分区名。
- 强制并行的最稳方式：显式指定目标分区，例如
INSERT INTO t PARTITION (p32) SELECT ... - 确保会话已启用并行 DML：
ALTER SESSION ENABLE PARALLEL DML，否则PARTITION提示也无效 - 源表扫描也要并行：对哈希分区源表，
SELECT /*+ PARALLEL(b,8) */ * FROM b PARTITION (p32)才能真正启动并行读 - APPEND 模式要求目标表无活动事务、无触发器、且
NOLOGGING可选但非必需（归档模式下可用/*+ APPEND_VALUES */）
哈希分区键选错会导致写热点，但很难被发现
哈希分区看似均匀，实际依赖键值分布质量。如果分区键（如 user_id）本身存在倾斜（少数用户占 80% 订单），哈希后仍可能集中在几个分区，表现为这些分区的 buffer busy waits 高、索引块分裂频繁、PCTFREE 被快速耗尽。
验证方法：查 DBA_TAB_PARTITIONS 的 NUM_ROWS 和 AVG_ROW_LEN，再结合 V$SEGMENT_STATISTICS 看各分区的 logical reads 和 db block changes 是否严重不均。
- 避免用业务主键直接哈希；优先选高基数+均匀分布字段，如
order_id（非自增序列）或组合键MOD(user_id * 1000 + order_seq, 64) - 哈希分区数建议设为 2 的幂次（32/64/128），避免 Oracle 内部取模运算低效
- 上线前做压力测试：用真实数据分布模拟并发插入，监控
v$session_event中latch free和enq: TX事件占比
哈希分区的并发插入优化，核心不在“分得更细”，而在“让索引少干活、让并行敢干活、让数据别挤在一起”。很多 DBA 调整分区数或换分区类型，却忽略 UNUSABLE + REBUILD 这种秒级见效的操作，或者忘了 ENABLE PARALLEL DML 这个开关——它不报错，只是默默让所有并行提示失效。
