数据库主键ID生成战略
系统独一 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 生成战略的细致内容，更多请关注 百分百源码网 其它相干文章！
