Oracle序列值不能直接用JDBC executeQuery获取？
开门见山地说，这个问题的答案是：不能。很多开发者习惯性地想用JDBC的executeQuery去执行一个SELECT，然后从ResultSet里拿到序列值。这个思路在Oracle里行不通。原因很简单：序列的NEXTVAL是一个伪列，它不是表里的字段，你不能像查询普通数据那样去“获取”它。
当然，技术上你确实可以写一句SELECT seq_name.nextval FROM dual来单独查询。但请注意，这恰恰是我们要避免的“起点”。这种做法不仅低效——因为它为了一次插入凭空多了一次数据库往返（round-trip）——更关键的是，它破坏了原子性，极易在并发场景下引发事务一致性问题。
那么，什么才是正确的“姿势”？核心原则就一条：把序列的递增和数据的插入捆绑在一起，让数据库在一个原子操作中完成，Ja va层只负责接收最终结果。 让专业的人（数据库）做专业的事，而不是在应用层拆分成多个步骤。
- 错误示范：先
select seq_name.NEXTVAL from dual取ID，再用这个ID去执行INSERT。这是典型的反面教材。 - 推荐路径：根据你的Oracle版本，选择
PreparedStatement配合RETURNING子句（12c及以上版本），或者用存储过程封装（旧版本）。 - 一个硬性前提：你的JDBC驱动版本必须跟得上，至少是12.1以上，否则
RETURNING子句可能无法被正确识别或返回空值。
Oracle 12c+：用 RETURNING 直接获取刚插入的主键
如果你的环境是Oracle 12c或更新版本，那么恭喜，你拥有目前最优雅、最高效的解决方案。它的思路非常直观：在INSERT语句中直接使用序列填充主键，并立刻通过RETURNING子句把刚生成的值“捞回来”。
String sql = "INSERT INTO user_info(id, name, email) VALUES (user_seq.NEXTVAL, ?, ?) RETURNING id INTO ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, "Alice"); ps.setString(2, "alice@example.com"); ps.registerOutParameter(3, Types.NUMERIC); // 注意：第3个?是OUT参数，类型要匹配序列类型（通常NUMBER） ps.execute(); Long newId = ps.getLong(3); // 直接拿到新ID
使用这个方法，有几个细节必须盯紧：
RETURNING ... INTO ?中的那个问号，必须通过registerOutParameter明确注册为输出参数。类型建议使用Types.NUMERIC或Types.DECIMAL，避免使用Types.INTEGER导致大数值被截断。- 这个方法有个小局限：它不支持JDBC的批量插入操作（
addBatch），一次只能插入一行并取回一个ID。 - 务必注意数据类型的匹配。即便你的序列定义从1开始简单递增，但如果实际值已经增长到千万甚至亿级，用
getInt()去接收就会溢出。保险起见，统一用getLong()或getBigDecimal()。
Oracle 11g 或 JDBC 驱动太老：改用存储过程封装 NEXTVAL
现实情况往往是，生产环境的数据库版本或驱动升级没那么快。当RETURNING子句用不了时，我们的策略是把序列获取的逻辑下沉到数据库端，用存储过程来封装。
首先，在数据库中创建一个简单的存储过程：
CREATE OR REPLACE PROCEDURE get_next_user_id(p_id OUT NUMBER) AS BEGIN SELECT user_seq.NEXTVAL INTO p_id FROM DUAL; END;
然后在Ja va中，通过CallableStatement来调用它：
立即学习“Ja va免费学习笔记（深入）”；
CallableStatement cs = conn.prepareCall("{CALL get_next_user_id(?)}");
cs.registerOutParameter(1, Types.NUMERIC);
cs.execute();
Long id = cs.getLong(1);
选择这条路径，有几点需要权衡：
- 相比在Ja va里直接拼接SQL查询
DUAL表，存储过程提供了更好的封装性和控制力，未来如果想改为缓存序列或UUID生成方式，改动范围也更集中。 - 需要注意的是，这本质上仍然是一次独立的数据库查询。如果你紧接着要执行INSERT，必须确保这两个操作在同一个数据库事务中，否则理论上存在极小的概率出现间隙或并发冲突。对于一般系统这可能不是问题，但在金融等高敏感场景下需要仔细评估。
- 再次强调，绝对要避免在Ja va代码里用字符串拼接的方式执行
SELECT ... NEXTVAL FROM DUAL。这既绕过了PreparedStatement的预编译和参数绑定，容易引入SQL注入漏洞，也会让Oracle无法重用执行计划，影响性能。
MyBatis 或 Hibernate 怎么办？别手写 NEXTVAL
对于使用MyBatis或Hibernate这类ORM框架的团队，好消息是：框架已经为你处理好了大部分细节。强行自己手动去获取序列值，反而会破坏框架的抽象层，可能引发主键重复、空指针等意想不到的问题。
- MyBatis：使用
order="BEFORE"并指定keyProperty即可。例如：SELECT user_seq.NEXTVAL FROM DUAL useGeneratedKeys="true"来使用更原生的方式。 - Hibernate：配置更简单，使用
@SequenceGenerator注解配合@GeneratedValue(strategy = GenerationType.SEQUENCE)即可。关键是确保sequenceName和数据库中实际的序列名一致。如果使用Hibernate 5.2+并连接Oracle 12c，可以尝试启用hibernate.id.new_generator_mappings=true属性来优化序列获取策略。 - 一个常见的坑：切忌在实体类的
@PrePersist生命周期回调方法中，手动去执行序列查询。这可能导致同一个实体对象在持久化（flush）前被多次触发，造成序列号的浪费和跳号。
最后，需要建立一个正确的认知：Oracle序列的设计目标首先是唯一性和单调递增，并不绝对保证连续性。在并发环境下，真正的风险点往往不在于“如何更快地取到值”，而在于是否保证了“获取序列”与“插入数据”这两个操作处于同一个事务和数据库连接上下文中。把握住这个核心，问题就解决了一大半。
