如题，我的使用场景是随机读写，需要保证尽可能高的性能。
一般来说 oracle 使用中都是使用序列代替 mysql 的自增主键功能。但是由于不了解 oracle 储存原理，不知道这个策略对于需求来说是不是最优的（考虑到分库分表的情况后）。因为今天看隔壁 mysql 主键的帖子想到比如 innodb 底层就不太适合用 uuid 做主键，会导致一些问题比如所有索引包含主键压缩率增加很多，还有 IO 方面的问题。想问一下有没有了解的朋友对于 oracle 来说使用 uuid 是否不存在类似问题，使用序列是否有什么坑，谢谢。
 |
1
gt15207 Mar 21, 2022
纯维护 DBA ，所以不知道 Oracle 里应用使用 uuid 是否存在什么问题；可能之前碰到过问题，但不知道应用使用的是 uuid 。不过有一个万金油的方案，就是搭建一个 POC 测试，尽量模拟应用行为，并做压力测试，看看 Oracle 能不能 hold 住。
至于使用序列： 1. 在 Real Application Cluster 下使用序列会出现多个实例里拿的序列号不是严格递增的情况。因为序列一般在每个 RAC 节点上有 cache ，比如节点一 cache 了序列号 1 到 20, 然后节点二 cache 了 21 到 40 。节点二上的应用初始拿到的序列号就会是 21 ；而此时序列号 20 大概率还没分给应用使用呢（也就是序列号 21 先于 20 被分配了） 2. 在序列号被默认 cache 的情况下，如果 DB crash ，则内存中 cache 住的序列号会丢失。也就是丢掉的序列号不会被分配给应用了。 3. 如果关闭序列号的 cache 功能，则分配序列号的动作会变慢（ Real Application Cluster/RAC 下此时需要节点间同步，所以分配序列号动作会变得更慢) 一般如果应用需要严格递增，而且不能缺号的序列号，是不应该使用 Oracle 自带的 sequence 技术的。 |
|
2
gt15207 Mar 21, 2022  1
抱歉，审题审错了，原来要用序列号做主键呀。Oracle 的主键默认会建成一个索引，所以它和 MySQL innodb 应该是类似的情况。但根据我个人的经验，在 Oracle 里用 sequence 做主键比用 uuid 做主键更容易造成热块争用；这和那个 MySQL 帖子里讲的恰恰相反 - 囧。
|
 |
3
LeeReamond OP @gt15207 感谢分享，很有用的经验，性能方面比较在意的是热块争用以及储存上的碎片问题，这在 mysql 里存在但不太清楚 oracle 的情况，如果不存在 mysql 的种种问题的话似乎 uuid 是很不错的选择。我们目前没有严格递增的需求，不过考虑到这个需求的话，简单想了一下好像也不感觉业务处理会有啥更快的方法，就算搞一个业务锁处理节点同步也很费时间啊
|
Select Language