关于UUID，GUID，OCMB

         UUID是是128位整数(16字节)的全局唯一标识符(Universally Unique Identifier)，指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成UUID的API。UUID按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。由以下几部分的组合：当前日期和时间(UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同)，时钟序列，全局唯一的IEEE机器识别号（如果有网卡，从网卡获得，没有网卡以其他方式获得），UUID的唯一缺陷在于生成的结果串会比较长。关于UUID这个标准使用最普遍的是微软的GUID(Globals Unique Identifiers)。 

UUID，其格式为：xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx(8-4-4-16)，其中每个 x 是 0-9 或 a-f 范围内的一个十六进制的数字。而标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxxxx-xxxxxxxxxx (8-4-4-4-12)

 

       在建立数据库的时候，需要为每张表指定一个主键，所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。数据库的主键生成有多种方式，每种方式都有其优点和缺点，应该根据不同的需求在主键的时间和空间效率上做平衡折中，从而选择不同的主键生成策略。归纳起来，对主键的选择主要有以下四种方式：

1.     自动增长字段

         自动增长型字段允许我们在向数据库添加数据时，不考虑主键的取值，记录插入后，数据库系统会自动为其分配一个值，确保绝对不会出现重复。

2.     手动增长字段

         手动增长型的字段，也就是说主键的值需要自己维护，通常情况下需要建立一张单独的表存储当前主键键值。

3.     GUID类型

         GUID是Globally Unique IDentifier的缩写，是一个128位的随机数,并保证不产生重复。

4.     COMB类型

         COMB（combine）型可以理解为一种改进的GUID，它通过组合GUID和系统时间，以使其在索引和检索事有更优的性能。  

下表列出四种主键生成方式优缺点的比较：
COMB类型主键生成实现:

主键生成策略	优点	缺点
自动增长字段	1.  使用简单	1.        不同数据库获取当前值方式不同； 2.        难以应用在多个数据库间进行数据迁移的情况。
手动增长型字段	1.        可以获得最新键值 2.        可以确保数据合并过程中不会出现键值冲突	1.        通常情况下需要建立一张单独的表存储当前主键键值； 2.        增加一次数据库访问来获取当前主键键值； 3.        考虑并发冲突等，增加系统的复杂程度。
使用GUID	1.        直接生成GUID，获得最新键值以填充主键，使用方便； 2.        可以确保数据合并过程中不会出现键值冲突； 3.        避免了前两种方式获取当前键值所增加的开销。	1.        占用较多存储空间； 2.        索引耗时； 3.        在多表链接查询时效率不如int型
使用“COMB”类型	1.        保留GUID的已有优点； 2.        利用时间信息与GUID组合起来，增加有序性以提高索引效率。	1.        需要设计COMB的生成算法； 2.        和GUID一样占用较多存储空间； 3.        在多表链接查询时效率不如int型，但优于GUID。

 

COMB数据类型的基本设计思路是这样的：既然GUID数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么能不能通过组合的方式，保留GUID的10个字节，用另6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与GUID组合起来，在保留GUID的唯一性的同时增加了有序性，以此来提高索引效率。

下面转自：温少，首发于博客园

替代方案之一，就是使用关系数据库的自增长字段，自增长字段的一个问题是，无法预先创建一个ID，只能够在保存的时候才能生成ID，这对于批量关联插入数据来说，不满足需求。

替代方案之二，就是使用一个记录ID的表，每次加一，在事务中使用Select FOR UPDATE来读取然后UPDATE SET FVALUE = FVALUE + 1，或者使用我之前文章中所提到的CAS算法。 这样做，会导致性能低下，每生成一个ID的成本都很高。

替代方案之三，就是把ID分成两部分，Seed和IncrementID。Seed采用上面的方案二或者其他办法生成，IncrementID使用一个AtomicInteger来每次递增生成。SEED转化为九进制数字，这样SEED就不会包含9，于是使用9作为分隔符，把SEED和IncrementID隔开。这样做，就可以做高性能产生ID，而且确保不重复。甚至可以更进一步，SEED由一个中心服务器生成。使用9个分隔符号隔开SEED和IncrementID，好处是SEED是变长，而不是使用固定位数来保存SEED，这样产生的ID会更短，可读性更好。

举例，34915，其中34时SEED，15是IncrementID，9是分隔符，SEED部分采用九进制表示法，确保不出现9，第一个9之后的内容属于IncrementID。