主键生成策略看似是数据库设计中的小问题，实际上它直接影响表的存储布局、索引性能和系统未来的水平扩展能力。在Oracle环境中，开发者通常在两种方案之间犹豫：一种是使用数据库原生的序列（SEQUENCE）生成有序的整数主键，另一种是使用SYS_GUID函数或应用程序生成UUID作为全局唯一标识。两种方案没有绝对的优劣，关键在于理解它们在底层机制上的差异，再结合业务场景做出选择。
序列的工作原理与性能特性
序列是Oracle提供的一种数据库对象，用于生成单调递增的整数。它的核心价值在于：多个会话可以并发地从同一个序列取值而不会产生重复，Oracle通过内部的闩锁机制保证了这一点。创建一个序列非常简单：
CREATE SEQUENCE seq_order_id START WITH 1 INCREMENT BY 1 CACHE 500 NOCYCLE;
这里需要重点关注CACHE参数。Oracle默认会预先在内存中缓存20个序列值，上面显式设置为500。缓存的意义在于减少访问底层序列字典表的次数：应用程序每次取NEXTVAL时，Oracle直接从内存分配，只有缓存耗尽时才会去磁盘更新序列元数据。将CACHE调大之后，序列生成的开销可以降到接近零，即使在高并发插入场景下也几乎不会成为瓶颈。
使用序列作为主键还有一个常被忽视的优势：索引的顺序插入特性。Oracle的B树索引按主键值排序存储，序列产生的值单调递增，新数据总是追加到索引最右侧的叶子块中，旧的索引块保持稳定。这种模式下索引空间利用率高，块的分裂多为5比5分裂之后快速填满，碎片化程度低，缓冲区缓存命中率也高，因为热点集中在少数几个索引块上。
序列的缺点同样明显。首先它是数据库层面的对象，在分布式环境下，如果多个数据库实例各自建序列，即使设置不同的起始值和步长，后续扩容也会变得僵硬。其次是可预测性，连续或规律递增的ID会暴露业务量信息，订单量、用户增长速度都可能被外部推测出来，一些安全敏感场景需要额外处理。
UUID作为主键的利与弊
UUID是128位的全局唯一标识符，理论上可以在任何节点独立生成而不产生冲突。Oracle中可以通过SYS_GUID函数获得一个16字节的RAW类型值：
SELECT RAWTOHEX(SYS_GUID()) FROM dual; -- 结果示例：7A8F2E1B4C3D5E6F8901ABCDEF234567
UUID最大的好处是生成过程完全去中心化。应用服务器、手机客户端、离线设备都可以独立生成ID，不需要依赖数据库，天然适合分库分表、多数据中心部署以及消息队列、日志追踪这类跨系统传递标识的场景。这也是微服务架构中UUID被广泛使用的原因。
但把UUID直接用作Oracle表的主键，代价不小。第一是存储成本：一个RAW(16)占16字节，而一个NUMBER类型的序列ID通常只占5到6字节，主键还会被冗余存储到每一个二级索引中，存储膨胀会被放大。第二是性能问题：随机UUID导致索引插入位置完全无序，每次插入都可能落在索引的任意叶子块上，缓存命中率下降，频繁的块分裂造成索引碎片化，表和索引的空间利用率通常只有60%到70%。第三是可读性和调试便利性差，排查问题时面对一串十六进制远不如面对一个整数直观。
如果确实需要UUID的分布式特性，又想减少随机性带来的伤害，可以考虑UUID v7这类基于时间戳前缀的方案，让生成的值在时间维度上大致有序，从而部分恢复顺序插入的性能优势。不过Oracle的SYS_GUID本身不带时间排序语义，需要应用层自己实现或引入第三方库。
分布式场景下的折中方案与选型建议
除了纯粹的序列和UUID，工程实践中还有不少折中方案。雪花算法（Snowflake）是其中的代表：它用一个64位整数拼接时间戳、机器标识和序列号，既保证了全局唯一，又保持了时间上的大致递增。在Oracle中，雪花ID可以直接用NUMBER(19)存储，占用空间与序列ID接近，同时支持多节点独立生成。
-- 雪花ID在Oracle中的典型建表方式 CREATE TABLE t_order ( order_id NUMBER(19) PRIMARY KEY, order_no VARCHAR2(64), created_time DATE DEFAULT SYSDATE );
还有一种常见做法是双ID并存：表内部使用序列主键保证索引性能，同时增加一个UUID列作为对外暴露的业务标识。内部关联、连接查询走整数主键，对外接口、分享链接、分布式追踪走UUID。这种设计在互联网业务中非常普遍，代价是多了一列存储和索引维护成本，但换来了性能与灵活性的平衡。
具体怎么选，可以参考以下判断依据：
- 单库或RAC集群内的传统业务系统：优先使用序列，将CACHE设置得足够大，性能最好、实现最简单。
- 分库分表、多数据中心、客户端离线生成ID的场景：使用UUID或雪花算法，其中对存储和索引性能敏感的表优先选雪花ID。
- 对外暴露的资源标识（订单号、分享链接）：使用UUID或经过编码处理的无规律ID，避免泄露业务量。
- 需要全局追踪的微服务调用链、事件消息：统一使用UUID，跨系统传递最方便。
总结来说，序列胜在有序和高效，UUID胜在去中心化和不可预测。绝大多数Oracle系统并不需要在两者之间二选一，更合理的思路是分场景组合使用：核心交易表用序列或雪花ID支撑高性能写入，对外标识层用UUID保证灵活与安全。主键设计是系统早期的关键决策之一，值得在动手建表之前多花一点时间想清楚。