Oracle主键自增的4种实现方式及最佳实践
1. Oracle主键自增的四种实现方式详解
第一次接触Oracle数据库时，最让我头疼的就是主键自增的实现。跟MySQL的AUTO_INCREMENT不同，Oracle需要多步操作才能实现类似功能。经过多年项目实践，我整理了四种最常用的实现方式，每种都有其适用场景。
先说说为什么需要主键自增。在电商系统中，用户表每秒钟可能新增上百条记录，手动维护ID既不现实也不安全。主键自增不仅能保证唯一性，还能提高插入性能。Oracle 12c之前，开发者只能通过序列+触发器的方式实现，现在有了更多选择。
2. Identity Columns新特性（Oracle 12c+）
这是Oracle 12c引入的新特性，用起来最像MySQL的AUTO_INCREMENT。我在金融项目升级到Oracle 19c时首次尝试，确实省心不少。
具体建表示例：
CREATE TABLE orders ( order_id NUMBER GENERATED ALWAYS AS IDENTITY, customer_name VARCHAR2(50), order_date DATE DEFAULT SYSDATE );关键点在于GENERATED ALWAYS和GENERATED BY DEFAULT的区别：
ALWAYS强制使用自增值，如果手动指定ID会报错BY DEFAULT允许手动指定ID，仅在未指定时使用自增
实测发现几个注意事项：
- 性能比传统序列快约15%（在100万条数据插入测试中）
- 不能直接修改自增步长，需要重建表
- 12c之前的版本无法使用
适合场景：新项目且确定使用Oracle 12c及以上版本时首选。
3. 默认序列方式
这是我最推荐的传统实现方式，兼容所有Oracle版本。在物流系统中处理日均10万+订单时表现稳定。
实现步骤分两步：
首先创建序列：
CREATE SEQUENCE seq_orders INCREMENT BY 1 START WITH 1000 MAXVALUE 999999999 NOCACHE NOCYCLE;然后建表时设置默认值：
CREATE TABLE orders ( order_id NUMBER DEFAULT seq_orders.NEXTVAL, customer_id NUMBER, order_total NUMBER(10,2) );几个优化技巧：
- 生产环境建议使用CACHE 20以上减少序列调用开销
- 初始值设为1000可以避免与测试数据混淆
- NOCYCLE防止主键循环使用导致冲突
常见坑点：使用DBeaver等工具时，新增记录后需要刷新才能看到生成的ID。
4. 触发器方式
早期项目中使用较多的方案，现在除非特殊需求，否则不建议使用。在医疗系统中遇到过触发器性能问题。
典型实现：
CREATE OR REPLACE TRIGGER orders_trigger BEFORE INSERT ON orders FOR EACH ROW BEGIN SELECT seq_orders.NEXTVAL INTO :NEW.order_id FROM dual; END;主要问题：
- 调试困难，触发器错误可能导致静默失败
- 批量插入时性能下降明显
- 增加系统复杂度
唯一优势：可以实现在插入前修改其他字段的值，适合特殊业务场景。
5. 显式序列调用
最灵活但也最麻烦的方式，我在对接老旧系统时不得已使用过。
插入数据时需要显式调用：
INSERT INTO orders (order_id, customer_id) VALUES (seq_orders.NEXTVAL, 1001);MyBatis中的Mapper写法示例：
<insert id="insertOrder"> INSERT INTO orders (order_id, customer_id) VALUES (seq_orders.NEXTVAL, #{customerId}) </insert>实际使用中发现的问题：
- 开发人员容易忘记调用序列
- 批量插入时代码冗长
- 主键生成逻辑分散在各处
6. 性能对比与最佳实践
通过JMeter对四种方式压测结果（100并发，1万次插入）：
| 方式 | 平均响应时间 | TPS |
|---|---|---|
| Identity | 23ms | 4200 |
| 默认序列 | 25ms | 3900 |
| 显式序列 | 28ms | 3600 |
| 触发器 | 45ms | 2200 |
根据实战经验，给出以下建议：
- 新项目优先使用Identity Columns
- 需要兼容老版本时选择默认序列方式
- 触发器方式仅用于特殊业务需求
- 显式调用适合需要精确控制主键的场景
维护小技巧：定期检查序列使用情况，避免接近MAXVALUE：
SELECT seq_name, last_number, max_value FROM user_sequences;7. 常见问题解决方案
问题1：Identity列如何修改起始值？
-- 只能通过重建表实现 ALTER TABLE orders MODIFY (order_id GENERATED BY DEFAULT AS IDENTITY (START WITH 1000));问题2：序列缓存导致跳号怎么办？
- 业务系统不应该依赖连续主键
- 确实需要时可设置NOCACHE，但会影响性能
问题3：多数据源如何保证主键不冲突？
- 每个数据源使用不同的序列起始值
- 或者使用复合主键
问题4：MyBatis如何返回自增ID？
<selectKey keyProperty="orderId" resultType="long" order="BEFORE"> SELECT seq_orders.NEXTVAL FROM dual </selectKey>8. 实战中的经验分享
在电商大促期间，我们遇到过序列缓存导致的性能问题。当时使用默认序列方式，CACHE设置为默认的20。当每秒插入量超过1000时，出现了明显的序列等待。
解决方案是调整CACHE大小：
ALTER SEQUENCE seq_orders CACHE 1000;另一个教训是关于触发器方式的。某次系统升级后，触发器逻辑出现问题，导致批量导入时部分订单没有生成ID。由于是静默失败，直到对账时才发现，最终不得不停机修复。
对于分库分表场景，我的做法是：
- 主库序列：START WITH 1 INCREMENT BY 10
- 从库序列：START WITH 2 INCREMENT BY 10 这样可以通过ID末尾数字快速判断数据来源