当前位置:Gxlcms > PHP教程 > uuid作为主键,还是用自增呢?

uuid作为主键,还是用自增呢?

时间:2021-07-01 10:21:17 帮助过:27人阅读

我在网上找了好久,有的人说uuid比较好,就是在分库分表,合并数据什么的比较容易,也有的人说自增好,到了表的数据多的时候,性能比uuid好得多,到底那种比较好呢?有没有在真实生产环境的大神,来给出一个完整的解答?

回复内容:

我在网上找了好久,有的人说uuid比较好,就是在分库分表,合并数据什么的比较容易,也有的人说自增好,到了表的数据多的时候,性能比uuid好得多,到底那种比较好呢?有没有在真实生产环境的大神,来给出一个完整的解答?

首先UUID的性能并不比自增ID差很多,这取决于UUID的生成算法。举个例子MongoDB所采用的ObjectId就是一个比较优秀的UUID策略,其组成是时间戳+机器码+进程码+自增数,其中机器码和进程码都可以一次性生成,这样得到一个ObjectId仅仅之比自增ID多了一个时间戳的获取。另外考虑到自增ID都要做主键唯一索引,而UUID可以只做索引,不做唯一索引(利用其特性,可以不考虑唯一性过滤),其性能可以说并不比自增ID差。

至于使用UUID还是自增ID主要还是看项目是否足够庞大,数据量是否足够多。从使用方便性上来说自增ID使用简单,不需要额外支持,而UUID相对麻烦一些,涉及到UUID算法的选取、程序的嵌入等等。而从应对庞大系统的效果上来说,UUID就比自增ID显得优秀得多。怎么选择就是看自己的实际情况,按需选择。

Oracle环境下(其他数据库没有使用经验):
长远来说,自增Number的占用空间比UUID(raw(16)占用32字节)更大,但一般表的数据量在数百亿以内时number占用的空间还是更少;
UUID使用没有number方便,UUID存储为raw(16)时查询条件需要使用HEXTORAW转换;
相同行数情况下,基于UUID的索引占用空间比number更大,数据量上去了读取磁盘次数肯定就更多了;
并发或者rac集群环境下,因为热块现象UUID的性能高于number(建立反向索引可解决这个问题);
UUID使用于前台展示时更安全,Number可以猜测

  1. 如果这个 id 会暴露给用户的话(URL的一部分),那么自增ID 更友好。

  2. 性能方面 2 个差距不太大

  3. 开发方便性的话,UUID 比 自增ID 要方便的多

    • UUID 可以解决分布式ID不冲突,数据库自增ID不支持。

    • UUID 可以在提交数据库之前就获取,不需要多一个 select 语句

    • 不是所有数据库都支持自增ID

  4. UUID可以不采用标准的36位长度,可以用base64压缩到12-16位长度。

  5. 优先采用UUID方案,如果需要更友好的 URL,也应该采用 sequence 代替自增ID

上面大部分答案从开发人员角度比较uuid生成效率,而对数据库的存取效率案例看,用InnoDB或TokuDB的话,答案就是自增主键,看看Oracle ACE的这篇解答:
为什么InnoDB表要建议用自增列做主键

按需所取,具体问题具体分析,简单的说,一般 32字节的UUID 可以通用

自增在索引上有优势(整型的比较比字符串比较要快),但优势有限。两者的区别最主要在于id是在client端/server端生成。 相对于mysql来说,java程序就是一个client端。uuid可以保证client端生成一个唯一且不重复的id,这在分布式系统中非常重要。

如果你摸不准的话,我建议你使用uuid.

这个要看你底层存储的选型,Oracle我不熟,他底层使用rowid来完成,所以不发表评论。其他类似MongoDB等都有自己特殊性,所以用UUID倒反合适。

但如果你的底层存储用MySQL,而且存储引擎又恰好是Innodb,那我是非常推荐你使用唯一自增的数字来作为你的PK;

首先不去探讨UUID和long这两个数据在CPU进行计算时分别对应多少个指令和CPU计算周期,最重要的是Innodb的底层存储是B+Tree,需要按照一个聚集索引,所有的数据查询操作都是基于聚集索引来完成(如果表设计了PK,则聚集索引默认选用就是这个PK)

如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话,这时候存取效率是最高的。

当然了,如果你的系统不追求性能的极限,那随便玩

为什么不定制自己的主键策略呢?

mysql的使用自增的,不然innodb也要自己维护主键索引的。

如果是单机, 推荐使用mysql的自增id.

如果是分布式环境, 想要保持全局的唯一id, 自增和uuid都不行。
这个时候就需要自已定制一套id生成机机制了

【注意】
我遇到过GUID重复,所以,直接用GUID做唯一主键是有潜在问题的!

(GUID是UUID标准的一种实现)

这个感觉还是要看具体的场景吧,如果只是一台数据库服务器的话,并且业务逻辑并不复杂,完全可以使用自增ID的方式,简单开发;如果是仅有少量的几台主数据库服务器也可以使用自增ID,但需要做一些处理。

对于分布式的,也就是有多台主数据库服务器的情况再使用自增ID就会使开发变得复杂,自增ID会变得越来越难控制,这时候何不用UUID呢,毕竟两者的性能也没差多少

人气教程排行