最有效手段是增大cache值，因nocache或cache=1时每次nextval均需磁盘io、加锁和日志写入，而cache预分配多值至内存可大幅减少争用；实测cache 50较cache 1耗时降低95%以上。
直接改 cache 值是最有效、最立竿见影的手段——默认 nocache 或 cache 1 时，每次 nextval 都要写磁盘、刷日志、加锁，高并发下极易成为瓶颈；设为 cache 20 或更高后，oracle 一次预分配多值到内存，后续调用几乎不触发磁盘 io。
为什么 Oracle 序列在高并发下变慢
序列值本身不存表里，但每次 NEXTVAL 必须保证全局唯一且有序，Oracle 通过序列对象的内存缓存 + 数据字典行级锁 + 日志记录来保障。当 CACHE 为 1 或 NOCACHE 时：
- 每个请求都需获取序列对象的独占锁（
SEQ$表中对应行），大量线程争抢同一把锁 - 每次递增都要写重做日志（哪怕只改一个数字），IO 压力陡增
- 无缓存意味着每次都要从数据字典读取当前值、加 1、再写回，三步全走磁盘路径
实测：100 并发线程连续取 my_seq.NEXTVAL，CACHE 1 下平均耗时 8–12ms；CACHE 50 后压至 0.3–0.6ms。
如何安全调整 Sequence 的 CACHE 值
不能直接 ALTER SEQUENCE ... CACHE N 就完事——必须确认当前使用方式是否允许跳号，以及是否已有应用依赖“绝对连续”语义：
-
ALTER SEQUENCE my_seq CACHE 50;是合法语法，但执行后旧缓存失效，下次NEXTVAL可能跳过若干值（比如原缓存剩 3 个，新缓存从 1000 开始预占 50 个） - 如果业务接受跳号（绝大多数主键场景都接受），这是最推荐做法；若严格要求不跳号，只能停服清空所有缓存再重建序列
- 避免设过大（如
CACHE 10000）：实例崩溃时未用完的缓存值永久丢失，重启后从下一个缓存块起用，跳号幅度变大 - 建议值区间：20–200，视并发峰值和单次批量插入量而定；例如每批插 100 条，就设
CACHE 100
JDBC 层配合优化：别在循环里反复查 NEXTVAL
即使序列已开启缓存，Java 端若在 for 循环中逐条调用 SELECT my_seq.NEXTVAL FROM DUAL，仍会因网络往返和 Statement 解析拖慢整体吞吐：
- 改用批量预取：一次查
SELECT my_seq.NEXTVAL FROM DUAL CONNECT BY LEVEL ，拿到 100 个值缓存在本地 List 中复用 - 避免 PreparedStatement 包裹
NEXTVAL：Oracle 不支持参数化序列名，硬编码也没问题，但 PreparedStatement 无法复用执行计划，反而多一层解析开销 - 不要用 Hibernate 的
@GeneratedValue(strategy = GenerationType.SEQUENCE)默认配置——它默认每条 insert 都触发一次NEXTVAL查询；应显式配allocationSize = 50并确保 sequence 定义匹配
容易被忽略的陷阱：RAC 环境下的 CACHE 冲突
在 Oracle RAC 多节点部署中，各实例有独立的序列缓存，CACHE 值过小会导致跨节点取值“乱序”更明显（不是错，是设计如此），但更危险的是：
- 若某节点异常终止，其未用完的缓存值不会归还，其他节点继续分配，可能造成更大范围跳号
- RAC 下序列的
ORDER属性（ALTER SEQUENCE ... ORDER）会强制所有节点串行取值，彻底消灭乱序，但性能暴跌——高并发下应禁用ORDER，接受逻辑上“非严格递增” - 监控关键指标：
v$system_event中的enq: SQ - contention等待事件，出现即说明序列争用已成瓶颈
真正卡住你的往往不是算法或代码，而是序列那行 CACHE 配置——它藏得深、影响广、改起来快，但很多人连查都没想到去查。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
