1. Sequence ID

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

优点： 简单，代码方便，性能可以接受。 数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点： 不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。 在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。 在性能达不到要求的情况下，比较难于扩展。 如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。 分表分库的时候会有麻烦。 优化方案： 针对主库单点，如果有多个Master库，则每个Master库设置的起始数字不一样，步长一样，可以是Master的个数。 比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。这样就可以有效生成集群中的唯一ID，也可以大大降低ID生成数据库操作的负载。

2. UUID

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

优点： 简单，代码方便。 全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。

缺点： 没有排序，无法保证趋势递增。 UUID往往是使用字符串存储，查询的效率比较低。 存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。 传输数据量大 不可读。 优化方案： 为了解决UUID不可读，可以使用UUID to Int64的方法。

3. GUID GUID：是微软对UUID这个标准的实现。

UUID还有其它各种实现，不止GUID一种。优缺点同UUID。

4. 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。 5. Twitter的snowflake算法（雪花算法） snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。snowflake算法可以根据自身项目的需要进行一定的修改。比如估算未来的数据中心个数，每个数据中心的机器数以及统一毫秒可以能的并发数来调整在算法中所需要的bit数。几乎可以保证全球唯一。 优点： 不依赖于数据库，灵活方便，且性能优于数据库。 ID按照时间在单机上是递增的。

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

作者：让你变好的过程从来都不会很舒服 链接：https://www.jianshu.com/p/e0698975a42f 来源：简书