This topic created in 1497 days ago, the information mentioned may be changed or developed.
如题，我的使用场景是随机读写，需要保证尽可能高的性能。
一般来说 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