前言：
系统唯一 ID 是我们在设计一个系统的时候常常会遇见的问题，下面介绍一些常见的 ID 生成策略。
●
本文来源gao!daima.com搞$代!码网
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。
转载请注明原文链接：数据库主键 ID 生成策略
