系统唯一 ID 是我们在设计一个系统的时候常常会遇见的问题，下面介绍一些常见的 ID 生成策略。
● Sequence ID
● UUID
● GUID
● COMB
● Snowflake
最开始的自增 ID 为了实现分库分别的需求，会在自增的前提下，使用不同起点，但需要做数据库拓展时，极其麻烦。 比如刚开始时，我们设计某个系统的数据库时，这个数据库中会有 10 个表，SQL为表中添加主键，那么我们对于每个表的内容都需要不同的 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
1 Gengeral 中定义表名，表空间。2 Columns 对字段进行定义。3 在Key选择主键字段，定义主键名称，一般用表名。不能“Apply” 一般是定义不完全。oracle：甲骨文公司，全称甲骨文股份有限公司(甲骨文软件系统有限公司)，是。
数据库自增长序列或字段，最常见的方式。由数据库维护，数据库唯一。
优点：
简单，代码方便，性能可以接受。
数字 ID 天然排序，对分页或者需要排序的结果很有帮助。
缺点：
不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。
在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。
在性能达不到要求的情况下，比较难于扩展。
如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。
分表分库的时候会有麻烦。
优化方案：
针对主库单点，如果有多个 Master 库，则每个 Master 库设置的起始数字不一样，步长一样，可以是 Master 的个数。
比如：Master1 生成的是 1，4，7，10，Master2 生成的是 2，5，8，11 Master3 生成的是 3，6，9，12。这样就可以有效生成集群中的唯一 ID，也可以大大降低 ID 生成数据库操作的负载。
1、打开navicat工具，连接上mysql服务器，选择完数据库之后，选择一个表右击选择设计表（这里为了演示测试，随便选择一个表即可）。2、在设计表页面，可以看到当前表的所有字段信息，我们选择的学生表有一个id字段，目前该表没。
第二部分：UUID
npm 管理
常见的方式，128 位。可以利用数据库也可以利用程序生成，一般来说全球唯一。
UUID 是 128 位的全局唯一标识符，通常由 32 字节的字符串表示。它可以保证时间和空间的唯一性，也称为 GUID，全称为：UUID ―― Universally Unique IDentifier，Python 中叫 UUID。
它通过 MAC 地址、时间戳、命名空间、随机数、伪随机数来保证生成 ID 的唯一性。
UUID 主要有五个算法，也就是五种方法来实现。
（1）、uuid1()
（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 往往是使用字符串存储，查询的效率比较低。
存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
传输数据量大
不可读。
设置主键：1、通过终端进入到mysql命令行工具。2、通过use关键字进行到目标数据库里。3、如原表已有主键，先把原来的主键删除掉，通过DROPPRIMARYKEY命令：ALTERTABLE`jingyan`DROPPRIMARYKEY。4、主键已经没有了。。
优化方案：
为了解决 UUID 不可读，可以使用 UUID to Int64 的方法。
企业回数据库 Database 主要用于事务处理，数据仓库Data Warehouse 主要用于数据分析。用途上的不同决定了这两种架构的特点不同。SelectDB作为新一代实时数据仓库的代表产品，支持日志分析，报表分析，用户画像分析，数据湖分析，ETL分析等各场景数据。
第三部分： GUID
GUID：是微软对 UUID 这个标准的实现。UUID 还有其它各种实现，不止 GUID 一种。优缺点同 UUID。
第四部分： COMB
数据库中没有 COMB 类型，它是 Jimmy Nilsson 在他的 “The Cost of GUIDs as Primary Keys” 一文中设计出来的。\
通过int或bigint设置。自增列的类型应为int或bigint型，可以设置起始和每次递增数。如：createtable[table1]([id][int]identity(1,1)。)这样每次插入则不需要为主键设置参数，数据库会根据设置的递增条件，自动给出主键。
优点：
解决 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());
