数据库主键 ID 生成策略 MySQL数据库使用教程

前言：　

系统唯一 ID 是我们在设计一个系统的时候常常会遇见的问题，下面介绍一些常见的 ID 生成策略。

● Sequence ID

● UUID

● GUID

● COMB

● Snowflake

最开始的自增 ID 为了实现分库分别的需求，会在自增的前提下，使用不同起点，但需要做数据库拓展时，极其麻烦。 比如刚开始时，我们设计某个系统的数据库时，这个数据库中会有 10 个表，那么我们对于每个表的内容都需要不同的 ID 我们就可以使用不同不长自增的形式，比如，第一张表的是 1、11、21、31。。。 第二张表是 2、12、22、32。。。 第三张表是 3、13、23、33。。。 第十张表就是 10、20、30。。。 但是这样的问题就是，如果有一天我发现这个系统的 10 张表已经不够用了，我想要再添加一张表，那么这时的主键应该怎么分配呢？ 另外，如果对于多个数据库的数据希望合并，但是对于这种简单的生成 ID 方式，重复的可能性很大，所以几乎一定会发生重复这种情况。 显然，如果使用之前的方法的可扩展性会比较差。

相比自增 ID，UUID 生成唯一主键更加方便（数据量非常大的情况下，存在重复的可能），但由于 UUID 的无序性，性能不如自增 ID，字符串储存，储存空间大，查询效率低。关键：使用 uuid 的缺点是查询效率低啊！

COMB 相对于 UUID，增加了生成 ID 的有序性，插入与查询效率都有所提高。 这篇文章有简单的分析。

Sonwflake 是 Twitter 主键生成策略，可以看做是 COMB 的一种改进，用 64 位的长整型代替 128 位的字符串。ID 构成：第一位 0 + 41 位的时间前缀 + 10 位的节点标识 + 12 位的 sequence 避免并发的数字。

第一部分：Sequence ID

数据库自增长序列或字段，最常见的方式。由数据库维护，数据库唯一。

优点：

简单，代码方便，性能可以接受。

数字 ID 天然排序，对分页或者需要排序的结果很有帮助。

缺点：

不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。

在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。

在性能达不到要求的情况下，比较难于扩展。

如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。

分表分库的时候会有麻烦。

优化方案：

针对主库单点，如果有多个 Master 库，则每个 Master 库设置的起始数字不一样，步长一样，可以是 Master 的个数。

比如：Master1 生成的是 1，4，7，10，Master2 生成的是 2,5,8,11 Master3 生成的是 3,6,9,12。这样就可以有效生成集群中的唯一 ID，也可以大大降低 ID 生成数据库操作的负载。

第二部分：UUID

npm 管理 https://www.npmjs.com/package/uuid

常见的方式，128 位。可以利用数据库也可以利用程序生成，一般来说全球唯一。

UUID 是 128 位的全局唯一标识符，通常由 32 字节的字符串表示。它可以保证时间和空间的唯一性，也称为 GUID，全称为：UUID ―― Universally Unique IDentifier，Python 中叫 UUID。

它通过 MAC 地址、时间戳、命名空间、随机数、伪随机数来保证生成 ID 的唯一性。

UUID 主要有五个算法，也就是五种方法来实现。

（1）、uuid1()

――基于时间戳。由 MAC 地址、当前时间戳、随机数生成。可以保证全球范围内的唯一性，但 MAC 的使用同时带来安全性问题，局域网中可以使用 IP 来代替 MAC。

（2）、uuid2()

基于分布式计算环境 DCE（Python 中没有这个函数）。算法与 uuid1 相同，不同的是把时间戳的前 4 位置换为 POSIX 的 UID。实际中很少用到该方法。

(3)、uuid3()

基于名字的 MD5 散列值。通过计算名字和命名空间的 MD5 散列值得到，保证了同一命名空间中不同名字的唯一性，和不同命名空间的唯一性，但同一命名空间的同一名字生成相同的 uuid。

（4）、uuid4()

基于随机数。由伪随机数得到，有一定的重复概率，该概率可以计算出来。

（5）、uuid5()

基于名字的 SHA-1 散列值。算法与 uuid3 相同，不同的是使用 Secure Hash Algorithm 1 算法。

优点：

简单，代码方便。

全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。

缺点：

没有排序，无法保证趋势递增。

UUID 往往是使用字符串存储，查询的效率比较低。

存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。

传输数据量大

不可读。

优化方案：

为了解决 UUID 不可读，可以使用 UUID to Int64 的方法。

第三部分： GUID

GUID：是微软对 UUID 这个标准的实现。UUID 还有其它各种实现，不止 GUID 一种。优缺点同 UUID。

第四部分： COMB

COMB（combine）型是数据库特有的一种设计思想，可以理解为一种改进的 GUID，它通过组合 GUID 和系统时间，以使其在索引和检索事有更优的性能。

数据库中没有 COMB 类型，它是 Jimmy Nilsson 在他的 “The Cost of GUIDs as Primary Keys” 一文中设计出来的。\

COMB 数据类型的基本设计思路是这样的：既然 UniqueIdentifier 数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么我们能不能通过组合的方式，保留 UniqueIdentifier 的前 10 个字节，用后 6 个字节表示 GUID 生成的时间（DateTime），这样我们将时间信息与 UniqueIdentifier 组合起来，在保留 UniqueIdentifier 的唯一性的同时增加了有序性，以此来提高索引效率。

优点：

解决 UUID 无序的问题，在其主键生成方式中提供了 Comb 算法 (combined guid/timestamp)。保留 GUID 的 10 个字节，用另 6 个字节表示 GUID 生成的时间 (DateTime)。

性能优于 UUID。

第五部分： Twitter 的 snowflake 算法

snowflake 是 Twitter 开源的分布式 ID 生成算法，结果是一个 long 型的 ID。其核心思想是：使用 41bit 作为毫秒数，10bit 作为机器的 ID（5 个 bit 是数据中心，5 个 bit 的机器 ID），12bit 作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是 0。snowflake 算法可以根据自身项目的需要进行一定的修改。比如估算未来的数据中心个数，每个数据中心的机器数以及统一毫秒可以能的并发数来调整在算法中所需要的 bit 数。

优点：

不依赖于数据库，灵活方便，且性能优于数据库。

ID 按照时间在单机上是递增的。

缺点：

在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况。

六、使用

这个使用起来是真的方便：

npm install uuid --save

然后就可以使用啦！

  const uuidv1 = require(‘uuid/v1‘);
  console.log(‘随机uuid字符串‘, uuidv1());

这样，我们就可以打印出来 uuid 字符串了。 每次的都不一样。

以上就是数据库主键 ID 生成策略的详细内容，更多请关注本站其它相关文章！