我们在使用MySQL的时候,主键的选择上一般有两种,那就是UUID和自增主键ID,使用这两个做主键各自都有哪些优缺点呢?为什么建议优先使用自增主键ID呢? UUID(Universally Unique Identifier)全局唯一标识符,是指在一台机器上生成的数字,它的目标是保证对在同一时空中的所有机器都是唯一的。 UUID 的生成是基于一定算法,通常使用的是随机数生成器或者基于时间戳的方式,生成的 UUID 由 32 位 16 进制数表示,共有 128 位(标准的UUID格式为:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12),共32个字符) 由于 UUID 是由 MAC 地址、时间戳、随机数等信息生成的,因此 UUID 具有极高的唯一性,可以说是几乎不可能重复,但是在实际实现过程中,UUID有多种实现版本,他们的唯一性指标也不尽相同。 UUID在具体实现上,有多个版本,有基于时间的UUID V1,基于随机数的 UUID V4等。 Java中的java.util.UUID生成的UUID是V3和V4两种: Version 4 这种是最简单的(也是我们最常用的),只是基于随机数生成的,但是也是最不靠谱的。适合数据量不是特别大的场景下。 Version 3是基于名称空间的,所以在一定范围内是唯一的,而且如果有需要生成重复UUID的场景的话,这两种是可以实现的。 很多人选择UUID作为主键,其实也是有一定道理的,那就是UUID有几何好处:
但是,如果只是因为这几个好处就选择UUID当做主键ID的话,那么也不是很好的方案,因为他的缺点也比较明显,如: 存储空间比较大:UUID 通常以字符串形式存储,占用的存储空间比较大。 不适合范围查询:因为不是自增的,所以在做范围查询的时候是不支持的。 不方便展示:主键ID有的时候会需要在系统间、或者前台页面展示,如果是UUID的话,就因为比较长、并且没有任何业务含义,所以不方便展示。 查询效率低: 在UUID列上创建索引,因为他很长,所以索引的大小会变得非常大。大的索引会占用更多的磁盘空间,导致缓存命中率下降,进而增加了磁盘I/O的需求。此外,大的索引还会导致查询时的内存开销增加。 当使用UUID进行排序时,新的UUID值通常会插入到叶子节点的中间位置。这可能导致B+树的页分裂和平衡操作频繁进行,从而增加了写入的开销。每次分裂或平衡都涉及到数据的重新排序和移动,这会影响查询的性能。 在 MySQL 中,可以通过设置 AUTO_INCREMENT 属性实现ID的自增长,通常可以用来作为主键ID。 使用自增ID做主键的好处是:
但是,使用自增主键做主键ID也存在一定的问题:
所以,在实际选型过程中,大家需要结合自己的实际业务做选择。 简单的业务场景,数据量不大,增删改查也不频繁,可以选择用UUID。 内部系统,数据量增删改查频繁,有频繁的分页查询和展示等需求,优先选择自增主键ID。 对外系统,数据量不大,也可以选用自增主键ID。 对外系统,数据量大,分库分表,则考虑使用雪花算法生成全局唯一ID。 |
|