数据库表数据的唯一ID是在设计一个系统的时候常常会遇见的问题，这里记录一些常见的ID生成策略。
Sequence ID
UUID
GUID
COMB
Snowflake
Redis分布式锁+incr 生成id
Zookeeper分布式锁生成id
MongoDB对象ID
百度UidGenerator
美团Leaf
最开始的自增ID为了实现分库分别的需求，会在自增的前提下，使用不同步长(例如DB1 生成1,4,7,10，DB2生成2,5,8,11，DB3生成3,6,9,12)，但需要做数据库拓展时，极其麻烦。
相比自增ID，UUID生成唯一主键更加方便（数据量非常大的情况下，存在重复的可能），但由于UUID的无序性，性能不如自增ID，字符串储存，储存空间大，查询效率低。
COMB相对于UUID，增加了生成ID的有序性，插入与查询效率都有所提高。见Integer GUID和Comb做主键的效率测试(Delphi+access)(三)
Sonwflake是Twitter主键生成策略，可以看做是COMB的一种改进，用64位的长整型代替128位的字符串。ID构成：第一位0 + 41位的时间前缀 + 10位的节点标识 + 12位的sequence避免并发的数字。见Twitter-Snowflake（64位分布式ID算法）分析与JAVA实现
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按照时间在单机上是递增的。
缺点：
在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况。
6、 Redis分布式锁+incr 生成id
SimpleDateFormat dateFormat=new SimpleDateFormat(“YYYYmmDDHHMMss”);
String id = dateFormat.format(new Date())+”_”+ jedisPool .getResource().incr(“orderId”);
7、 使用Zookeeper分布式锁生成id
InterProcessMutex mutex=new InterProcessMutex(client, “/OrderId”);
mutex.acquire();
String id=OrderId();
mutex.release();
8、 MongoDB对象ID
mongodb设计的初衷是用作分布式数据库，在mongodb的文档中必须有一个”_id”键，这个键的值可以是任何类型的，默认是个ObjectId。如果插入的文档没有“_id”键，那么系统会自动帮我们创建一个，由服务器自动创建。
ObjectId使用12字节的存储空间，是一个由24个十六进制数字组成的字符串（每两个字节 可以存储两个十六进制数字）。ObjectId的12个字节按照如下的方式生成：
0|1|2|3|4|5|6|7|8|9|10|11
时间戳 |机器 |pid|计数器
9、 百度UidGenerator
UidGenerator是百度开源的分布式ID生成器，基于于snowflake算法的实现。
10、 美团Leaf
Leaf 是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、Zookeeper等中间件。